Re: [jakarta.ee-spec.committee] Ideas for downloads area and binary sign

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

David Blevins wrote on 7/17/19 11:24 AM:
> Here is what we already have in-hand and completed with regards to the download and setup.  This can be adjusted.  I'm happy to work with Mikael on the infra team on whatever changes we want.  Our status is that after several weeks of not getting a Jenkins instance for the specification committee, once I finally got his time I pushed forward as we don't have a lot of time.
> 
> Our created Jenkins instance is here:
> 
>  - https://ci.eclipse.org/jakartaee-spec-committee
> 
> Our agreed website layout for each spec and version on the jakarta.ee website is this:
> 
>  - https://jakarta.ee/spec/servlet/3.4/<stuff>

No, we were told (by Wayne, I think) that it would be

https://jakarta.ee/specifications/servlet/3.4/<stuff>

We've been using that in the TCK User Guides that we've been updating,
and I just told the web team to use that name.

(I don't really care whether it's named "specifications" or "spec" or "specs",
I'm just tired of going back and forth on these trivial details.)

> Based on that I gave Mikael direction to enable us to have the same structure for the download area.  As a result he created this base directory for us and gave the `jakartaee-spec-committee` Jenkins instance write access:
> 
>  - https://download.eclipse.org/jakartaee/
> 
> The above is what we have completed.
> 
> PROPOSAL
> 
> The proposal from here would be create a directory structure under https://download.eclipse.org/jakartaee/ that matches the agreed https://jakarta.ee website structure.  For example:
> 
>  - https://jakarta.ee/spec/servlet/3.4/<stuff>
>  - https://download.eclipse.org/jakartaee/servlet/3.4/<stuff>
> 
>  - https://jakarta.ee/spec/messaging/2.1/<stuff>
>  - https://download.eclipse.org/jakartaee/messaging/2.1/<stuff>
> 
> 
> DAY ONE ACCEPTABLE IMPL
> 
> The first implementation of this would be a parameterized Jenkins job that took the 1) spec name, 2) version and 3) staged TCK zip URL and promoted it into the above directory, signed.  This would give us:
> 
>  - https://download.eclipse.org/jakartaee/messaging/2.1/messaging-tck-2.1.zip
>  - https://download.eclipse.org/jakartaee/messaging/2.1/messaging-tck-2.1.zip.asc
>  - https://download.eclipse.org/jakartaee/messaging/2.1/messaging-tck-2.1.zip.sha1
> 
> The advantage is we don't really need to coordinate with projects right now.  We just paste in their staged TCK URL wherever it happens to point.

I agree this is fine.

Currently our TCK zip files are named like mailtck-1.6.0_10-Jul-2019.zip.
They definitely need the dot-dot version number to allow for updates to
the exclude list (for example).  (All approved versions should remain
available forever, not overwritten by newer approved versions.)

Do you want us to remove the date from the name?

Do you expect to rename the zip file when promoting and signing it?

> POST JAKARTA EE 8 IMPL
> 
> After we get through Jakarta EE 8 and we have the opportunity to give some clearer direction, we ask for 1) spec name, 2) version and 3) staged directory to promote that must contain a TCK zip at minimum.  We would sign and promote everything in the directory, so specifications should put anything in there they don't want available in their download directory.
> 
> A specification project might give us this directory to promote:
> 
>  - https://<someplace>/staging/servlet-5.2/servlet-tck-5.2.zip
>  - https://<someplace>/staging/servlet-5.2/servlet-examples.zip
>  - https://<someplace>/staging/servlet-5.2/whitepaper.pdf
>  - https://<someplace>/staging/servlet-5.2/somedir/anyfilename.zip
> 
> We would promote all their materials when we vote on their "5.2" release, as follows:
> 
>  - https://download.eclipse.org/jakartaee/servlet/5.2/servlet-tck-5.2.zip
>  - https://download.eclipse.org/jakartaee/servlet/5.2/servlet-examples.zip
>  - https://download.eclipse.org/jakartaee/servlet/5.2/whitepaper.pdf
>  - https://download.eclipse.org/jakartaee/servlet/5.2/somedir/anyfilename.zip
> 
> 
> ADVANTAGES
> 
> We are being asked as a specification committee to approve versions, so there is simplicity in having both the website and download directories think in terms of versions, allowing projects to have freedom on what goes underneath the version.
> 
> Our contract with projects is then basically: give us what you want promoted for your version 5.2 and we'll put those materials here and here:
> 
>  - https://jakarta.ee/spec/servlet/5.2/
>  - https://download.eclipse.org/jakartaee/servlet/5.2/
> 
> Anything they want directly in https://jakarta.ee/spec/servlet/5.2/ would be in the Github PRs commits.  Anything they want promoted to https://download.eclipse.org/jakartaee/servlet/5.2/ would be under a single link they give us.
> 
> Over time we can change where we put things with no impact to the promotion logic.  Today we want specs in the PR commit, which results in them being on https://jakarta.ee/spec/servlet/5.2/ unsigned by us.  In the future, we might decide they should be signed and we prefer projects to put it in their download directory resulting in this:
> 
>  - https://download.eclipse.org/jakartaee/servlet/5.2/servlet-5.2.pdf
>  - https://download.eclipse.org/jakartaee/servlet/5.2/servlet-5.2.pdf.asc
>  - https://download.eclipse.org/jakartaee/servlet/5.2/servlet-5.2.pdf.sha1
> 
> To make this happen we wouldn't need to make any changes to our Jenkins jobs.  Specifications would just arrange their materials differently upon our request.

I think this is generally fine although at this point I don't see any need to
sign the spec documents.

> NIGHTLY NEEDS
> 
> If we wanted to have a nightly directory where projects could have things promoted, we could probably accomplish that with a Jenkins job pretty easily.  It could be as simple as "tell us where you'll be putting files and we'll copy that dir nightly."  That could enable a directory like this:
> 
>  - https://download.eclipse.org/jakartaee/servlet/nightly/servlet-5.3-SNAPSHOT.pdf
>  - https://download.eclipse.org/jakartaee/servlet/nightly/servlet-5.3-SNAPSHOT.pdf
> 
> We could even delete the prior files before copying the new files in, which would keep it clean.
> 
> Alternatively, we can work with Eclipse infra to give specification projects direct access to their "nightly" directory:
> 
>  - https://download.eclipse.org/jakartaee/servlet/nightly/<servlet-specification-project-writable>
> 
> This is a nice-to-have if we can get it.

Projects already have their own download directory, which they can use for
nightly versions of whatever they want.  I think that's more than good enough.