Re: [jakarta.ee-spec] TCK URLs...

["Kevin Sutter" <sutter@xxxxxxxxxx>]

+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)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



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

---

>>> 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 _index.md file for the TCK location, we should
be specifying 
>>>> this directory structure:_
>>>> __https://download.eclipse.org/jakartaee/_
>>>> <http://download.eclipse.org/jakartaee/_>{spec}/x.y/jakarta-{spec}-tck-x.y.z.zip
>>>>  Â (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 
> https://www.eclipse.org/lists/jakartaee-tck-dev/threads.html#00858
> 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 
https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/staged-900
to 
https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/promoted,
we have created tracking issues for many of the TCKs.  To view the
open 
issues use 
https://github.com/eclipse-ee4j/jakartaee-tck/issues?q=is%3Aissue+is%3Aopen+Review+and+promote. 


In the 
https://www.eclipse.org/lists/jakartaee-tck-dev/threads.html#00858
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.

Scott

_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec