Amelia Eiras
twitter.com/ameliaeiras <https://twitter.com/ameliaeiras>
Tribe:http://tomitribe.com <http://tomitribe.com/>
https://tribestream.io <https://tribestream.io/>
OSS:http://microprofile.io https://jakarta.ee
On Mon, Aug 3, 2020 at 12:03 PM Scott Marlow <smarlow@xxxxxxxxxx
<mailto:smarlow@xxxxxxxxxx>> wrote:
On Mon, Aug 3, 2020 at 12:59 PM Amelia Eiras <aeiras@xxxxxxxxxxxxx
<mailto:aeiras@xxxxxxxxxxxxx>> wrote:
Hola Scott,
Hola Amelia,
Thanks for responding!
I have bias feedback on how the window to receive feedback ought
to be set up.
Bare with me and thanks for brainstorming after you consume this
message.
If an issue/PR is sent on Friday, do we expect the contributors
to work on it over the weekend?
I agree that we do not want them to work on it over the weekend.
If yes, why is that?
Should we assume that contributions ought to happen during the
work week instead?
+1
WHY?
the 72 hours period for example ought not to contain the wknd.
Whether it is 78 hours or some other amount of time, we still may
have additional standalone TCK documentation pull requests that come
in after we have "promotion" (e.g. copied to
https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/promoted/jakarta-annotations-tck-2.0.0.zip)
of the respective versioned TCK. For example, if
https://github.com/eclipse-ee4j/jakartaee-tck/issues/382 is promoted
on Wednesday instead of Tuesday, a contributor could notice on
Thursday that an important TCK documentation should be made, that we
could increment the version to jakarta-annotations-tck-2.0.1.zip and
stage/promote that.
Fyi, the "stage" term refers to copying the latest nightly TCK build
to
https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/staged-900
and "promotion" refers to creating a versioned TCK.
I'm not aware of any problems with promoting multiple versions of a
TCK, however there could be time constraints that dictate whether to
promote a specific TCK again.
We as a community can contribute any day we choose to, HOWEVER
we ought to be aware AND PROTECTIVE that weekends for many of us
are free of professional work-devices.
Another approach could be to start the time clock now by emailing
all of the various SPEC API contributors that their feedback on the
TCK documentation contained in the respective TCK zip in
https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/staged-900
is welcome in the form of pull requests on
https://github.com/eclipse-ee4j/jakartaee-tck. The advantage of
this approach is that contributors would have more time to contribute.
Another advantage of emailing all SPEC API contributors now is that
we don't yet have issues for all of the SPEC API TCKs created yet,
so sending a generic email to all could help get the message out
sooner so the TCK documentation pull requests can come in sooner.
As such, I would recommend that the August 4th gets moved to
later to honor that weekend ought not to be included (yet are
awesome plus to have) on the window to contribute.
Also of importance is to keep the SPEC API ballots moving along and
not getting blocked on the promotion of TCKs, as well as not getting
blocked on the TCK team creating the tracking issues for promoting TCKs.
So, if we delay the August 4th TCK promotions until August 6th and
send generic email today to all of the SPEC API mailing lists to
review their respective staged TCK zips (and create pull requests on
https://github.com/eclipse-ee4j/jakartaee-tck for further changes
that are needed), that might be more helpful.
The following schedule (from Ed's original email from this thread)
is what we are trying to achieve with regard to promoting the TCKs:
"
* Wave 0 (Any time)
* Concurrency
* Messaging
* Persistence
* (From the Platform TCK)
o Web Services Metadata
* Wave 1 (Any time)
* Annotations
* Expression Language
* JSON Processing
* Servlet
* SOAP with Attachments
* WebSocket
* Wave 2 (Planned to start July 28)
* Authentication
* Authorization
* JSON Binding
* Server Pages
* Wave 3 (Planned to start Aug 5)
* XML Web Services
* Wave 4 (Planned to start Aug 11)
* RESTful Web Services
* Transaction
* Wave 5 (Planned to start Aug 18)
* Connectors
* Standard Tag Library
* (From the Platform TCK)
o Enterprise Beans
o Enterprise Web Services
* Wave 6 (Planned to start Aug 25
* Security
* Server Faces
* Wave 7 (Planned to start Aug 31)
* Jakarta EE Web Profile
* Jakarta EE Platform
"
Stay awesome formidable #ossDOER and happy August to everyone here,
Thanks, you too! :-)
Scott
Amelia Eiras
twitter.com/ameliaeiras <https://twitter.com/ameliaeiras>
Tribe:http://tomitribe.com <http://tomitribe.com/>
https://tribestream.io <https://tribestream.io/>
OSS:http://microprofile.io https://jakarta.ee
On Mon, Aug 3, 2020 at 7:35 AM Scott Marlow <smarlow@xxxxxxxxxx
<mailto:smarlow@xxxxxxxxxx>> wrote:
On Thu, Jul 30, 2020 at 9:57 PM Scott Marlow
<smarlow@xxxxxxxxxx <mailto:smarlow@xxxxxxxxxx>> wrote:
The committer teams need to review the staged TCK
content and give their
+1 for the relevant TCK bundle to be promoted. The
promotion will
freeze the TCK for release, which essentially means it
is frozen. If a
blocking change in a TCK is needed, we will re-release
with a
incremented version number as mentioned below.
The possible states that TCKs can transition through are:
* Staged via
https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/staged-900
(each TCK zip may be updated multiple times).
* Promoted via
https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/promoted
(each versioned TCK zip is frozen immediately, further
changes can only
appear via a version number increment).
* Final release for Jakarta EE 9 via
https://download.eclipse.org/jakartaee/...
On 7/27/20 11:21 AM, Ed Bratt wrote:
> Due to how the Specification Committee has defined
the process, any
> change to the TCK requires are re-release -- Docs.
change, Exclude List
> change, anything else that would change content
and/or generate a build
> forces a version number increment.
>
> I think the procedures described below will allow us
to stop builds,
> once a Specification has gone to ballot. So, that's
my first concern. We
> just need to follow the ballot progress closely and
not inadvertently
> create an update that wasn't asked for.
From a process point of view, I think that the SPEC API
representative/lead/committers can help determine when
it is time for
the relevant TCK to transition from Staged to Promoted
state.
Question, if we don't hear feedback from a SPEC lead or
committers, who
can make the decision to proceed with Promoting the
TCK? Also how long
should we wait for feedback?
There is no perfect amount of time to wait for feedback, if
we make it too short, we may need to stage/promote a newer
standalone TCK version for further changes. If we make it
too long, we may never hear feedback and could
jeopardize the EE 9 schedule.
I'm thinking that we can wait a few days after pinging the
SPEC API teams (whether it is sending email or pinging
lead(s)).
For example, for
https://github.com/eclipse-ee4j/jakartaee-tck/issues/382 we
sent email to ca-dev@xxxxxxxxxxx <mailto:ca-dev@xxxxxxxxxxx>
on Friday July 31 and will
promote jakarta-annotations-tck-2.0.0.zip first thing on
Tuesday August 4, 2020 if we do not hear feedback.
Worse case, we could later stage
a jakarta-annotations-tck-2.0.1.zip if further TCK pull
requests for documentation changes are important.
Scott
Good news, it is now time for Staged
jakarta-annotations-tck-2.0.0.zip
to be reviewed via
https://github.com/eclipse-ee4j/jakartaee-tck/issues/382.
Feedback is
welcome (link to staged TCK zip is in the issue)!
Also good news, it is now time for Staged
jakarta-expression-language-tck-4.0.0.zip to be reviewed
via
https://github.com/eclipse-ee4j/jakartaee-tck/issues/387.
Once the relevant SPEC API lead and/or committers has
given their
approval via the relevant jakartaee-tck issue, we will
Promote the
related TCK.
We have created some other similar "Review and promote "
tracking issues
for other TCKs but help is needed to created tracking
issues for other
TCKs still (open
https://github.com/eclipse-ee4j/jakartaee-tck/issues?q=is%3Aissue+is%3Aopen+Review+and+promote
for current issues).
Scott
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
<mailto:jakartaee-tck-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx <mailto:jakartaee-tck-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx <mailto:jakartaee-tck-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev