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

[David Blevins <dblevins@xxxxxxxxxxxxx>]

> On Jul 17, 2019, at 12:55 PM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
> 
> 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.)

I'm also fine either way.  I likely misremembered the short 'spec'


>> 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?

With an "infrastructure" hat on, I was imagining creating something that did as little as possible.  So if the project handed us https://<some-staging-location>/mailtck-1.6.0_10-Jul-2019.zip and we the Specification Committee wanted to approve that, the infra would promote that as-is to their directory for that version, becoming:

 - https://download.eclipse.org/jakartaee/mail/1.6/mailtck-1.6.0_10-Jul-2019.zip
 - https://download.eclipse.org/jakartaee/mail/1.6/mailtck-1.6.0_10-Jul-2019.zip.asc (our signature)

Adding would ok.  Deleting would not, nor would overwriting.


With my spec committee hat on, I'm ok letting specification projects have some freedom here, but don't have a strong opinion.  If someone does imagine some naming convention, I'm ok with that.


>> 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.

Signed specifications had been mentioned by myself and Dan as a good way to have a "normative" document.  But I favor progress over perfection on this so as long as we have room to change our mind/evolve, I'm happy.


>> 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.

It's good enough for me as well.  It had been expressed keeping everything together was desirable, so the above was a way to accommodate that.  Good old fashioned symlinks could likely get the job done too.

Options are there should we decide to revisit in the future


-David