A note on release votes

[Stefan Bodewig <bo...@apache.org>]

Hi all,

in the past we have been a bit lax on releases.  We've beasically been
voting on the source tree (yes, you can build a release on Sunday) and
not on the files being released.  Now that we are sponsoring an
Incubator podling, we might better be a bit more strict so that the
Ivy community doesn't pick up our bad habits 8-)

Formally we don't even need a release plan, everybody can build
distribution files and start a release vote at any time, but I think
we should stick with our current procedure.

The second part is that after the distribution has been built, we must
vote on those distribution files before they are published.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: A note on release votes

[Steve Loughran <st...@apache.org>]

Stefan Bodewig wrote:
> On Sat, 28 Oct 2006, Antoine Levy-Lambert <an...@gmx.de> wrote:

> 
>> - since we will be releasing both to the maven directory tree and
>> using our usual distribution system, does the release manager also
>> need to upload the java-repository directory tree, maybe as a zip
>> file ?
> 
> I don't count publishing to the java-repository as a release, but
> probably you are right, we'd need to verify them as well.

Yes the repo people will tell you off if you release an artifact that 
isnt approved.

-steve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: A note on release votes

[Stefan Bodewig <bo...@apache.org>]

On Sat, 28 Oct 2006, Antoine Levy-Lambert <an...@gmx.de> wrote:

> This procedure for releases opens for me a number of questions :
> 
> - does it not force the project to actually hold two votes, one to
> choose a date to build a release candidate, the second to decide
> whether this release candidate is valid ?

No, only the second is necessary.  Anybody could say "look this is
what I'd like to release" and call for a vote any time.  I like our
more organized release plan vote better, though.

> - should the release manager tag the code in any case before
> building ? Now there is a danger that you create a tag ANT_170 but
> then you get a negative vote, this is not 1.7.0 any more.

I had this problem with AntUnit 1.0Beta2 - there I went ahead and
removed the old tag and created a new one.  Not sure whether this was
the best approach.

> - since we will be releasing both to the maven directory tree and
> using our usual distribution system, does the release manager also
> need to upload the java-repository directory tree, maybe as a zip
> file ?

I don't count publishing to the java-repository as a release, but
probably you are right, we'd need to verify them as well.

> - this procedure makes lose the time of the vote on the binary
> artifacts, where the release could actually already be made
> available

You wouldn't push them into the dist directory until the vote has
passed.

> - there is no clear calendar. I find it better if a project commits
> itself to some clear milestones

Nothing prevents us from doing this in addition to making sure our
release artifacts have been voted on "correctly".

> If you say this system of creating a release candidate, uploading it
> to ~release_manager/betadistribution, then voting on accepting this
> as version xyz is ASF procedure, then I will have to live with
> it.

AFAIU it is.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: A note on release votes

[Antoine Levy-Lambert <an...@gmx.de>]

Hello Stefan,

OK, maybe this does not comply with ASF procedures.
I see that tomcat seems to be doing releases the same way as what you
suggest and did for the antlib(s):

http://marc.theaimsgroup.com/?l=tomcat-dev&m=115859000312242&w=2

This procedure for releases opens for me a number of questions :

- does it not force the project to actually hold two votes, one to choose a date to build a release candidate,
the second to decide whether this release candidate is valid ? If you decide spontaneously to build a release candidate
on a random date-time, chances are that it will not be accepted

- should the release manager tag the code in any case before building ? Now there is a danger that you create a
tag ANT_170 but then you get a negative vote, this is not 1.7.0 any more. Maybe the solution in this case is to remove the tag in subversion.
Or can you create an interim tag called for instance ANT_170_build20061030123405 and rename the tag to something else if the corresponding build is 
accepted as a release

- in the case of ant, the release manager must build with the assumption that the artefacts are going to be accepted as version x.y.z. The version is in
defaultManifest.mf, in version.txt, in the naming of the artifacts.

- since we will be releasing both to the maven directory tree and using our usual distribution system, does the release manager also need to upload the java-repository directory tree,
maybe as a zip file ?

- this procedure makes lose the time of the vote on the binary artifacts, where the release could actually already be made available

- there is no clear calendar. I find it better if a project commits itself to some clear milestones

If you say this system of creating a release candidate, uploading it to ~release_manager/betadistribution, then voting on accepting this as version xyz is ASF procedure,
then I will have to live with it. But I will work to get the procedure changed towards more automation and more predictability. 

Regards,

Antoine


Stefan Bodewig wrote:
> On Fri, 27 Oct 2006, Antoine Levy-Lambert <an...@gmx.de> wrote:
>
>   
>> I prefer the procedure which I have used for Ant 1.6 and for the
>> betas of 1.7 to define a release date in the vote thread, and then
>> to build and publish the release "mechanically" on the release date.
>>     
>
> I may have been a bit unclear.  This process simply doesn't comply
> with ASF procedures.  We cannot vote on the release of an artifact
> that we haven't seen yet.  We are required to check that the actual
> released artifact is correct.  Where correct is determined by a number
> of criteria.
>
> http://incubator.apache.org/guides/releasemanagement.html
>
> There is something called RAT by Robert Burrel Donkins to check
> compliance of artifacts, this is used by quite a few incubator folks.
> I haven't used it myself yet.
>
> <http://code.google.com/p/arat/>
>
> Stefan
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: A note on release votes

[Stefan Bodewig <bo...@apache.org>]

On Fri, 27 Oct 2006, Antoine Levy-Lambert <an...@gmx.de> wrote:

> I prefer the procedure which I have used for Ant 1.6 and for the
> betas of 1.7 to define a release date in the vote thread, and then
> to build and publish the release "mechanically" on the release date.

I may have been a bit unclear.  This process simply doesn't comply
with ASF procedures.  We cannot vote on the release of an artifact
that we haven't seen yet.  We are required to check that the actual
released artifact is correct.  Where correct is determined by a number
of criteria.

http://incubator.apache.org/guides/releasemanagement.html

There is something called RAT by Robert Burrel Donkins to check
compliance of artifacts, this is used by quite a few incubator folks.
I haven't used it myself yet.

<http://code.google.com/p/arat/>

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: A note on release votes

[Antoine Levy-Lambert <an...@gmx.de>]

Stefan Bodewig wrote:
> Hi all,
>
> in the past we have been a bit lax on releases.  We've beasically been
> voting on the source tree (yes, you can build a release on Sunday) and
> not on the files being released.  Now that we are sponsoring an
> Incubator podling, we might better be a bit more strict so that the
> Ivy community doesn't pick up our bad habits 8-)
>
> Formally we don't even need a release plan, everybody can build
> distribution files and start a release vote at any time, but I think
> we should stick with our current procedure.
>
> The second part is that after the distribution has been built, we must
> vote on those distribution files before they are published.
>   
Hello Stefan,

I prefer the procedure which I have used for Ant 1.6 and for the betas
of 1.7 to define a release date in the vote thread,
and then to build and publish the release "mechanically" on the release
date.

Voting on the source tree seems for me the right thing to do. We should
automate the generation and the upload of the distribution as much as
possible so that
there is no leeway for the release manager to tweak the artifacts.

Ideally, the releases should be built fully automatically by a
server/script/program. It is quite easy to think how this would work.
For instance you would check in in a special directory a file
called release-ant-1.7.0.xml containing the date/time when to start the
build (in UTC), the subject and the text of the email messages to
announce the release, some pointers to generate the RELEASE-NOTES.html from
WHATSNEW, ...

I think that - apart from writing the script which could be done with
the technology we already know - the thing that would hold us from doing
it in the case of ant is that you would not put on a
"release.apache.org" server our non open source dependencies such as
weblogic and starteam because we do not know if this would create legal
problems.

Regards,

Antoine

> Stefan
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org