About releases and votes

[Andy Seaborne <an...@apache.org>]

Since we have a new PMC member, Chris, I thought I'd put down more 
detail than usual about releases.

There are some changes coming through about discouraging MD5.

There are some simplifications we can do about NOTICE and LICENSE files.

== The "Release"

The "release" is the source-release.zip file that will end up in 
/dist/jena/source/.

The files going into /binaries/ and the files going to maven central, 
including the copy of "source-release", are "convenience binaries".

Our process is documented at:

https://cwiki.apache.org/confluence/display/JENA/Release+Process

== Update to Apache release policy:

MD5 checksums are being discouraged for the source-release, the file 
that goes in https://www.apache.org/dist/jena/source/.

Files uploaded to maven central are not affected - they remain as 
md1/sha1/asc - and I think MD5/SHA1 is effectively baked into maven.

The Apache parent POM, does not seem to seem to deal with this so I'm 
proposing we add a manual step at about step 10 to calculate sha512 
checksums and delete the MD5 checksums

https://cwiki.apache.org/confluence/display/JENA/Release+Process#ReleaseProcess-Step10-UploadtheReleaseCandidate

(and change the download.html page).

== Possible future changes.

Now we are committed to a single release cycle for all modules, there is 
no need to have NOTICE and LICENSE files at the top of every module.  We 
can just have the ones in the top directory which should already be correct.

We do need separate N&L files to go into binaries like the Fuseki sever 
jar.  These are in "dist/" subdirectories in the codebase.

The W3C test suites need there own files.

== The Process

There are two parts - the basic of an Apache process (conducted 
properly, legal clean, signed) and what we as a community decide on top 
of that.

Strictly, a vote is at least 3 +1 and a simple majority (you can't veto 
a release, that should have happened when the code went into the codebase).

As a community, we haven't pushed through a release on that minimal 
basis before. We try to sort things out and do a new release candidate. 
Doing a 2nd, 3rd, ... release candidate isn't too bad although not zero 
cost. The most bumpy things have been instabilities in the test suite - 
unintended order dependencies and with random things on different 
hardware. Deciding on a case-by-case basis rather than a set of rules 
for all eventualities seems fine to me.

It does not have to be perfect. My view is that the question is "is it 
better?" We are shipping fixes and improvement.

We tend to classify modules into two groups: the principle modules which 
are a blocker on getting a release out, and rhe rest including legacy 
ones (e.g. Fuseki1, SDB).  At the moment, jena-maven-tools does not pass 
its test suite and is not in the build.

Ultimately, it's the Release Manager decision.

== Voting

The VOTE email will have various links and details in it:
All links are https and to Apache servers.
--------
Proposed dist/ area:
   -- URL to the files to go in  https://www.apache.org/dist/jena/
   -- You must download the "source/" area.
   https://dist.apache.org/repos/dist/dev/jena/

Keys:
   -- Keys to import to verify the .asc on source-release.zip.-----
   https://svn.apache.org/repos/asf/jena/dist/KEYS

Staging repository:
   -- URL to the files to go to maven central --
   https://repository.apache.org/content/repositories/orgapachejena-?????

Git commit (browser URL):
   -- URL to the commit on Apache hardware, not Github.
   http://git-wip-us.apache.org/repos/asf/jena/commit/??????

Git Commit Hash:
   -- full SHA1 hash of the commit.
   --    "[maven-release-plugin] prepare release ..."

Git Commit Tag:
   -- The tag. Note that tags in git can be moved later.
   -- It is the commit SHA1 that matters.
--------

When voting on a release candidate the following points need to be checked:

+ is there a source archive?
+ is the GPG signatures correct?
+ are the checksums correct?
+ does everything work?

+ can the source archive really be built?
      (NB This requires a "mvn install" first time)
+ is there a correct LICENSE and NOTICE file in each artifact
      (both source and binary artifacts)?
+ does the NOTICE file contain all necessary attributions?
+ have any licenses of dependencies changed due to upgrades?
      if so have LICENSE and NOTICE been upgraded appropriately?
+ does the tag/commit in the SCM contain reproducible sources?

--------