Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [jakartaee-tck-dev] Finalizing the TCKs 
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 <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

Back to the top