On 19/03/07, Vadim Gritsenko <[EMAIL PROTECTED]> wrote:
Henning Schmiedehausen wrote:
> Vadim,
>
> that is not the point. The procedure in itself is flawed.
You missed it too :) Existing procedure might be flawed in somebody's opinion,
and I'm not arguing that it is ideal, but proposed procedure is even worse. It
makes any release impossible: release packages can be made available only after
the release itself is made. This makes me think that such procedure comes from
the camp not taking SCM seriously.
Since the objective of the change to the process is to verify steps done by RM,
the only viable procedure, in my view, is - (1) vote on SVN rev number (with
packages made available), (2) tagging and building a release, (3) quick vote on
resulting files. It's quick sine no actual software testing need to be
performed, just verify that zip unzips and tar untars.
I think one also needs to check that:
* that the various signature files are present and correct
* the zips and tars contain the same files as each other
* the zips and tars and contained jars contain the required NOTICE and
LICENSE files
* the source archive includes all the required sources from SVN
* the bin archive includes all the required files (apart from any
documented dependencies)
I don't think these can be determined directly from the contents of an
SVN rev number, so need to be checked after a potential release has
been built.
==
As to release voting:
Surely the most important thing is to ensure that a build is not
released to the general public - i.e. not put in the dist tree -
before the vote has passed.
So long as the build files are in a private area - e.g. the RM's
public_html directory - (and maybe are named as pre-release) the vote
can be done on the actual files.
S///
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
