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 Wed, Aug 5, 2020 at 6:50 AM Scott Marlow <smarlow@xxxxxxxxxx
<mailto:smarlow@xxxxxxxxxx>> wrote:
Hola Amelia,
I removed the platform ml from this response as Kevin Sutter already
included enough information in his response.
On Tue, Aug 4, 2020 at 4:27 PM Amelia Eiras <aeiras@xxxxxxxxxxxxx
<mailto:aeiras@xxxxxxxxxxxxx>> wrote:
Hola Scott,
I am happy to help the wiki write-up after it is started :)
I started some draft updates to create a few levels of landing pages
via https://github.com/eclipse-ee4j/jakartaee-tck/wiki. Please do
let me know if you are able to create a pull request for the wiki.
I tried googling for how non-committers could do that but didn't
find a reasonable solution.
I added a question to the Q+A sub-page about how to add questions
and answered that questions can be added by sending mail to the
Platform TCK mailing list.
https://github.com/eclipse-ee4j/jakartaee-tck/wiki/Jakarta-EE-9-Platform-TCK-Questions---Answers
Sadly, I always have a conflict at 8am PDT on Tuesdays so I
cannot join the Platform calls, however like you said, there is
no need to wait to start lowering the bar to entry.
+1
I am most happy to work with you and other Jakartees on the
documentation.
Thank you!
Lets not wait to have everything figured out. If we start the
write up, it is most likely that #ossDOERs by jumping into help
with TCK, could help improve the process itself, I see them
submitting PRs against the documenation that in turn helps to
clarify the reality of HOW TCK Contributing Works. Mojo is:
try, fail-fast & openly, learn, unlearn & reiterate.
+1
Please pull me in when starting that write-up. See you in git,
my ID: aeiras.
I included "@aeiras" in the comment for a wiki page update, I'm not
sure if that is ignored or processed by github.
Abrazos,
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 Tue, Aug 4, 2020 at 9:23 AM Scott Marlow <smarlow@xxxxxxxxxx
<mailto:smarlow@xxxxxxxxxx>> wrote:
Amelia,
Adding platform-dev ml...
The Platform call wasn't scheduled for today, so perhaps
next week there
can be discussion about the below. I did think more about
this and
would like to propose a few adjustments to give the
community enough
time to give feedback but also meet our schedule constraints.
With regard to Standalone TCK deliverables, we can easily
stage new
builds of each Standalone TCKs, however we can only promote
a specific
versioned Standalone TCK once (with the last promoted TCK
version
targeted for EE 9 final release).
So from a TCK perspective, I propose that contributors
review TCK
documentation and create pull requests over the next N days,
where N is
to be discussed further (perhaps N could be 10 calendar days
including
some non-working days or some other duration yet to be
discussed).
Whatever N is for the final date to create TCK documentation
pull
requests by, each SPEC API ballot could work off of an
initial promoted
TCK (e.g. assuming no TCK test failures and initial TCK doc
changes are
merged).
If subsequent TCK documentation pull requests come in after
the SPEC API
ballot, the SPEC lead (or TCK team) could push a new staged
Standalone
TCK update that could then be promoted with the updated TCK
documentation.
The only negative is that each Standalone TCK that is
promoted after the
respective SPEC API ballot is approved, would need to be
copied to
http://download.eclipse.org/jakartaee (along with SHA sum).
I suggest that we start following ^ this week if no there
are no reasons
presented as to why we cannot abide by the current schedule
for SPEC API
ballots and also still merge in further TCK documentation
changes from
the community (while we have time left for doing that after
SPEC API
ballots complete but before EE 9 is final).
More responses inline below.
On 8/3/20 6:24 PM, Amelia Eiras wrote:
> Scott,
>
> I think your explanation is quite beneficial for
tomorrow's platform
> call, beyond that call and its minutes.
> Releases have a deadline, that means that expectations
need to be fluid
> yet clearly stated to simplify the process of the
release. I see you as
> a Mentor for this thread. :)
Thank you, I think that we all desire to bring more
community to the
Jakarta EE Platform TCK. IMO, we did very well with getting
community
contributions for the big bang "EE 8 ==> EE 9" changes but
not as much
for other TCK changes, which could be a number of reasons
(including
documentation/wiki need to provide more 'how thinks work'
guidance to
developers.)
>
> After I read your reply on the why of time, I finally
understood the
> workaround time-limits, the steps 1, 2... when dealing
with the TCK.
> I would go further and ask for us to start the wiki under
the TCK
> documenting this.
+1 I have been thinking that we should update the initial
wiki page to
be a proper landing page that links to sub-topics, so we can
have EE 9
development process topics as well as user oriented topics
(really,
should have no friction against adding any type of
sub-topics with no
limit on amount of nesting).
> With Jakarta EE, the TCK is public yet its process is
> a complete vacuum with bare to none documentation on what
to expect when
> contributing to it.
Yes, it is a lot different developing the TCK than just
using it, many
of the contributors may not be users of the TCKs yet, for those
contributors it is even harder to understand the TCK internals.
>
> Up until now, we have never discussed the bare minimum
expectations when
> TCK contributed. We ought to fix that.
+1
> Related to Jakarta EE contributing-- last week, I was
candidly asked via
> a Java public forum on a private slack group how much
time was ok to
> "wait" for a PR review/merge or git issue accomplishment
under the
> Jakarta EE project *before asking for help*. I said 72hrs
or so,
> patience and respect to Contributors of the project means
we understand
> that their time, YOUR, MINE, OURS, is the most precious
commodity & a
> contract if choosing to be a #ossDOER that wants to have
impactful
> contributions.
>
> Lastly, I believe candid conversations lead such as the
one you are
> beautifully facilitating lead to documentation.
Brainstorming and
> exchanges such as these ought to make you and I scalable.
+100 and thanks for taking the time to contribute here!
I see good
> ideas, values from those that care to share *a
> direct acknowledgement to scale stuff that is worth
broadening. * THAT I
> CARE THE MOST.
+100
>
> Hugs,
Ditto and have a great day! :-)
Scott
>
> Amelia Eiras
> twitter.com/ameliaeiras <http://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>
> <mailto:smarlow@xxxxxxxxxx <mailto:smarlow@xxxxxxxxxx>>>
wrote:
>
>
>
> On Mon, Aug 3, 2020 at 12:59 PM Amelia Eiras
<aeiras@xxxxxxxxxxxxx <mailto:aeiras@xxxxxxxxxxxxx>
> <mailto: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 <http://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>
> <mailto:smarlow@xxxxxxxxxx
<mailto:smarlow@xxxxxxxxxx>>> wrote:
>
>
>
> On Thu, Jul 30, 2020 at 9:57 PM Scott Marlow
> <smarlow@xxxxxxxxxx
<mailto:smarlow@xxxxxxxxxx> <mailto: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> <mailto: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>
> <mailto: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>
<mailto: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>
<mailto: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
>
