Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] TCK URLs...

+1, Scott, with this approach.  And, thanks for wading through all of the ideas and suggestions!  

Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    

From:        Scott Marlow <smarlow@xxxxxxxxxx>
To:        Jakarta specification discussions <>, David Blevins <dblevins@xxxxxxxxxxxxx>
Date:        08/07/2020 14:02
Subject:        [EXTERNAL] Re: [] TCK URLs...
Sent by:

>>> Question:  Should the Specification PRs include the TCK zip SHA as a
>>> way of ensuring that the TCK zip contents do not unexpectedly change
>>> during the PR process (or that TCK zip contents didn't change a
>>> second before the Spec Committee member ran the "promote" script)?
>> We did require the SHA in the PR during Jakarta EE 8.  It's certainly
>> my preference, but I understand how people find it cumbersome.
>>  However, it solves a lot of problems and provides a lot of freedoms.
>> Someday, I'd really love us to have a Github App that can help
>> automate some of the PR review process.  Ideally it'd compute the SHA
>> and add it as a comment.  It could even block a merge if the SHA has
>> changed.
>> Fancy ideas and no time :)
>>>> In the file for the TCK location, we should be specifying
>>>> this directory structure:_
>>>> __
>>>> <>{spec}/x.y/jakarta-{spec}
>>>>  Â (this is in our checklist, so I think we're good with this)
>>>> But, where should the "staged" version of the TCK be located?
>>> I'm tuned in here to find out. :-)
>> I was mid post in a new thread a few hours ago with some ideas.  I'll
>> try to get it finished and send it.
> Thanks David, I assume you mean the
> thread that you started.  I like the idea of including the SHA in the
> staged TCK name, as that makes it more obvious as to which TCK is
> intended to be in the pull request (so fewer mistakes or errors will
> happen, very nice!).

Hi all,

In the short term, I think that the Platform TCK team should continue to
stage new TCKs as the TCK documentation is updated (or tests fixed if
needed).  Each staged TCKs is subject to change until the Platform TCK
team is asked to promote a respective TCK, which means no more changes
are allowed to the (versioned) TCK zip (at least not without first
incrementing the version number).

Also, for communicating with the TCK team, as to when the TCK team
should promote a TCK zip from
we have created tracking issues for many of the TCKs.  To view the open
issues use

In the
thread we came up with good ideas for changing the staged TCK zip file
name (or contained folder name) to include the TCK zip SHA + (time of
staging) timestamp.

In terms of when to switch to this new process to use new names we could
slip that in at some point as long as it doesn't disrupt the teams
involved by much, however we will need to figure out the process changes
for dealing with the TCK SHA + timestamp in the file name or containing
folder name.


_______________________________________________ mailing list
To unsubscribe from this list, visit

Back to the top