On 19/03/07, Vadim Gritsenko <[EMAIL PROTECTED]> wrote:
sebb wrote:
> On 19/03/07, Vadim Gritsenko <[EMAIL PROTECTED]> wrote:
>> 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)

(This is done by ant, btw, and so is 99% reproducible)

It's the other 1% that is the problem ...


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

Hence I mentioned 'quick check of release files'. Would satisfy even procedure
extremists.

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

Actual files, as you might have noticed, are impossible to produce before
release is tagged. To tag a release, a vote must pass. Best you could do is to
produce 'rc' build off of trunk.

Surely voting on creating a tag (if this is necessary) is completely
different from voting on a release?

S

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to