You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by Josh Thompson <jo...@ncsu.edu> on 2009/09/18 21:40:11 UTC
what to vote on when doing a release
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
The only TODO item left in defining our release process
(http://cwiki.apache.org/VCL/cutting-a-vcl-release.html) is if and how to use
release candidates. Part of the release process is for the community to vote
on the release. For that to happen, a fixed collection of the code needs to
exist so that everyone is voting on the exact same thing (it wouldn't do for
people to vote on HEAD from svn because that could change from one person's
vote to another's).
There are a few options that exist for the fixed collection:
(1) pick a revision number from trunk or a branch
(2) create a tag
(3) go through the steps of making a release artifact, but label it a release
candidate (RC) and distribute it somewhere other than the official
distribution area
Here are the pros and cons I see right now:
(1) pros - very easy for the developers - just pick a revision number and
we're done
- because it's so easy, if a vote fails because of something that
that needs to be fixed, it's easy to fix it and pick a new
revision number
cons - not as easy for non-developers (i.e. people who aren't normally
using SVN to access to code) to test - this may result in fewer
people testing it, making the release more likely to have bugs
- it doesn't test the process of creating the artifact
(2) pros - not as easy as #1, but still pretty easy
- if a vote fails, just create another tag
cons - same cons as #1, plus:
- could result in many tags that could make subversion a little
cluttered
(3) pros - tests the process of creating the artifact
- easier for non-developers to test so could get better bug
reports
cons - more involved, so more effort that has to be repeated if a vote
fails
Please share your thought on which method you think would be best. If you can
think of another option that would be better, please share it. Also, if we
pick one option and decide we don't like it, we can change the process for
the next release.
Josh
- --
- -------------------------------
Josh Thompson
Systems Programmer
Advanced Computing | VCL Developer
North Carolina State University
Josh_Thompson@ncsu.edu
919-515-5323
my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFKs+IcV/LQcNdtPQMRAjiyAJ9JxnWPwngxXrFQ3Y8nVvcMBixDkQCfV/aN
LIwpZcuzaJrPJhW9U6gMbD0=
=/KuR
-----END PGP SIGNATURE-----
Re: what to vote on when doing a release
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
You are correct Josh. There is no need to be in the ASF WOT.
Regards,
Alan
On Oct 7, 2009, at 9:29 AM, Josh Thompson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Matt & Kevan,
>
> I just remembered I hadn't responded to these.
>
> Matt - I have added my key to the KEYS file in svn.
>
> Unless anyone is really against the idea, I'm going to go with what
> Kevan
> pointed out that my key isn't required to be in the Apache WOT.
>
> Josh
>
> On Thursday October 01, 2009, Kevan Miller wrote:
>> On Oct 1, 2009, at 6:20 PM, Matt Hogstrom wrote:
>>> Did you get your "key" where it needs to be ?
>>>
>>> On Sep 22, 2009, at 12:17 PM, Josh Thompson wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Based on Kevan's input, we'll go with options 2 and 3 - a tag to
>>>> make it easy
>>>> to see what the RC was based off of, and an actual RC artifact that
>>>> people
>>>> can vote on.
>>>>
>>>> I'll go ahead and add that to the "Cutting a VCL Release" and then
>>>> start on
>>>> the process outlined on that page. I can go ahead and sign it with
>>>> my key,
>>>> but I still need to get my key into the ASF WOT somehow.
>>
>> See http://www.apache.org/dev/release-signing.html#keys-policy
>>
>> You'll want a KEYS file in SVN and in the release dist directory.
>> Though good to have, it's not necessary to be in the Apache Web of
>> Trust.
>>
>> --kevan
> - --
> - -------------------------------
> Josh Thompson
> Systems Programmer
> Advanced Computing | VCL Developer
> North Carolina State University
>
> Josh_Thompson@ncsu.edu
> 919-515-5323
>
> my GPG/PGP key can be found at pgp.mit.edu
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFKzMH5V/LQcNdtPQMRAg7SAJoDpCGHzctg4yLyVQJAqAzg1KGP1QCeOEO+
> CXVRqozpc6eNVFGmOk62zgg=
> =ruhq
> -----END PGP SIGNATURE-----
Re: what to vote on when doing a release
Posted by Josh Thompson <jo...@ncsu.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matt & Kevan,
I just remembered I hadn't responded to these.
Matt - I have added my key to the KEYS file in svn.
Unless anyone is really against the idea, I'm going to go with what Kevan
pointed out that my key isn't required to be in the Apache WOT.
Josh
On Thursday October 01, 2009, Kevan Miller wrote:
> On Oct 1, 2009, at 6:20 PM, Matt Hogstrom wrote:
> > Did you get your "key" where it needs to be ?
> >
> > On Sep 22, 2009, at 12:17 PM, Josh Thompson wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Based on Kevan's input, we'll go with options 2 and 3 - a tag to
> >> make it easy
> >> to see what the RC was based off of, and an actual RC artifact that
> >> people
> >> can vote on.
> >>
> >> I'll go ahead and add that to the "Cutting a VCL Release" and then
> >> start on
> >> the process outlined on that page. I can go ahead and sign it with
> >> my key,
> >> but I still need to get my key into the ASF WOT somehow.
>
> See http://www.apache.org/dev/release-signing.html#keys-policy
>
> You'll want a KEYS file in SVN and in the release dist directory.
> Though good to have, it's not necessary to be in the Apache Web of
> Trust.
>
> --kevan
- --
- -------------------------------
Josh Thompson
Systems Programmer
Advanced Computing | VCL Developer
North Carolina State University
Josh_Thompson@ncsu.edu
919-515-5323
my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFKzMH5V/LQcNdtPQMRAg7SAJoDpCGHzctg4yLyVQJAqAzg1KGP1QCeOEO+
CXVRqozpc6eNVFGmOk62zgg=
=ruhq
-----END PGP SIGNATURE-----
Re: what to vote on when doing a release
Posted by Kevan Miller <ke...@gmail.com>.
On Oct 1, 2009, at 6:20 PM, Matt Hogstrom wrote:
> Did you get your "key" where it needs to be ?
>
> On Sep 22, 2009, at 12:17 PM, Josh Thompson wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Based on Kevan's input, we'll go with options 2 and 3 - a tag to
>> make it easy
>> to see what the RC was based off of, and an actual RC artifact that
>> people
>> can vote on.
>>
>> I'll go ahead and add that to the "Cutting a VCL Release" and then
>> start on
>> the process outlined on that page. I can go ahead and sign it with
>> my key,
>> but I still need to get my key into the ASF WOT somehow.
See http://www.apache.org/dev/release-signing.html#keys-policy
You'll want a KEYS file in SVN and in the release dist directory.
Though good to have, it's not necessary to be in the Apache Web of
Trust.
--kevan
Re: what to vote on when doing a release
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Did you get your "key" where it needs to be ?
On Sep 22, 2009, at 12:17 PM, Josh Thompson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Based on Kevan's input, we'll go with options 2 and 3 - a tag to
> make it easy
> to see what the RC was based off of, and an actual RC artifact that
> people
> can vote on.
>
> I'll go ahead and add that to the "Cutting a VCL Release" and then
> start on
> the process outlined on that page. I can go ahead and sign it with
> my key,
> but I still need to get my key into the ASF WOT somehow.
>
> Josh
>
> On Monday September 21, 2009, Kevan Miller wrote:
>> On Sep 18, 2009, at 3:40 PM, Josh Thompson wrote:
>>> (2) pros - not as easy as #1, but still pretty easy
>>> - if a vote fails, just create another tag
>>> cons - same cons as #1, plus:
>>> - could result in many tags that could make subversion a
>>> little
>>> cluttered
>>
>> A tag is best, IMO.
>>
>> If a vote fails, then you can always delete the corresponding
>> directory in tags/ (this reduces the apparent clutter). And then spin
>> a new release candidate for a new vote. Then a question of whether or
>> not your tags have unique names (e.g. 0.5-RC1, 0.5-RC2, etc or just
>> 0.5 w/ corresponding revision #). I've seen communities use either
>> approach. Personally, I prefer simple name (e.g. 0.5 and note the
>> revision number in the release).
>>
>> My current understanding is that: technically, a release vote is not
>> on the code that is in SVN. Instead the vote is on the source archive
>> that the release manager has created (which has been digitally
>> signed). Expectation is that the source archive matches the tag code
>> (and this should be verified during release vote).
>>
>> --kevan
> - --
> - -------------------------------
> Josh Thompson
> Systems Programmer
> Advanced Computing | VCL Developer
> North Carolina State University
>
> Josh_Thompson@ncsu.edu
> 919-515-5323
>
> my GPG/PGP key can be found at pgp.mit.edu
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFKuPiEV/LQcNdtPQMRAvSlAJ98hBqVT+E4z+0eKiCumqDkY9nLIACdFqI/
> aZn40Z4aBhEgHeyJuI6vsr8=
> =3UwY
> -----END PGP SIGNATURE-----
>
Re: what to vote on when doing a release
Posted by Josh Thompson <jo...@ncsu.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Based on Kevan's input, we'll go with options 2 and 3 - a tag to make it easy
to see what the RC was based off of, and an actual RC artifact that people
can vote on.
I'll go ahead and add that to the "Cutting a VCL Release" and then start on
the process outlined on that page. I can go ahead and sign it with my key,
but I still need to get my key into the ASF WOT somehow.
Josh
On Monday September 21, 2009, Kevan Miller wrote:
> On Sep 18, 2009, at 3:40 PM, Josh Thompson wrote:
> > (2) pros - not as easy as #1, but still pretty easy
> > - if a vote fails, just create another tag
> > cons - same cons as #1, plus:
> > - could result in many tags that could make subversion a
> > little
> > cluttered
>
> A tag is best, IMO.
>
> If a vote fails, then you can always delete the corresponding
> directory in tags/ (this reduces the apparent clutter). And then spin
> a new release candidate for a new vote. Then a question of whether or
> not your tags have unique names (e.g. 0.5-RC1, 0.5-RC2, etc or just
> 0.5 w/ corresponding revision #). I've seen communities use either
> approach. Personally, I prefer simple name (e.g. 0.5 and note the
> revision number in the release).
>
> My current understanding is that: technically, a release vote is not
> on the code that is in SVN. Instead the vote is on the source archive
> that the release manager has created (which has been digitally
> signed). Expectation is that the source archive matches the tag code
> (and this should be verified during release vote).
>
> --kevan
- --
- -------------------------------
Josh Thompson
Systems Programmer
Advanced Computing | VCL Developer
North Carolina State University
Josh_Thompson@ncsu.edu
919-515-5323
my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFKuPiEV/LQcNdtPQMRAvSlAJ98hBqVT+E4z+0eKiCumqDkY9nLIACdFqI/
aZn40Z4aBhEgHeyJuI6vsr8=
=3UwY
-----END PGP SIGNATURE-----
Re: what to vote on when doing a release
Posted by Kevan Miller <ke...@gmail.com>.
On Sep 18, 2009, at 3:40 PM, Josh Thompson wrote:
>
> (2) pros - not as easy as #1, but still pretty easy
> - if a vote fails, just create another tag
> cons - same cons as #1, plus:
> - could result in many tags that could make subversion a
> little
> cluttered
A tag is best, IMO.
If a vote fails, then you can always delete the corresponding
directory in tags/ (this reduces the apparent clutter). And then spin
a new release candidate for a new vote. Then a question of whether or
not your tags have unique names (e.g. 0.5-RC1, 0.5-RC2, etc or just
0.5 w/ corresponding revision #). I've seen communities use either
approach. Personally, I prefer simple name (e.g. 0.5 and note the
revision number in the release).
My current understanding is that: technically, a release vote is not
on the code that is in SVN. Instead the vote is on the source archive
that the release manager has created (which has been digitally
signed). Expectation is that the source archive matches the tag code
(and this should be verified during release vote).
--kevan
Re: what to vote on when doing a release
Posted by Aaron Peeler <aa...@ncsu.edu>.
I suggest #2. For the first release I doubt we'll have many tags.
Aaron
--On September 18, 2009 3:40:11 PM -0400 Josh Thompson
<jo...@ncsu.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> The only TODO item left in defining our release process
> (http://cwiki.apache.org/VCL/cutting-a-vcl-release.html) is if and how to
> use release candidates. Part of the release process is for the
> community to vote on the release. For that to happen, a fixed
> collection of the code needs to exist so that everyone is voting on the
> exact same thing (it wouldn't do for people to vote on HEAD from svn
> because that could change from one person's vote to another's).
>
> There are a few options that exist for the fixed collection:
>
> (1) pick a revision number from trunk or a branch
> (2) create a tag
> (3) go through the steps of making a release artifact, but label it a
> release candidate (RC) and distribute it somewhere other than the
> official distribution area
>
> Here are the pros and cons I see right now:
> (1) pros - very easy for the developers - just pick a revision number and
> we're done
> - because it's so easy, if a vote fails because of something that
> that needs to be fixed, it's easy to fix it and pick a new
> revision number
> cons - not as easy for non-developers (i.e. people who aren't normally
> using SVN to access to code) to test - this may result in fewer
> people testing it, making the release more likely to have bugs
> - it doesn't test the process of creating the artifact
>
> (2) pros - not as easy as #1, but still pretty easy
> - if a vote fails, just create another tag
> cons - same cons as #1, plus:
> - could result in many tags that could make subversion a little
> cluttered
>
> (3) pros - tests the process of creating the artifact
> - easier for non-developers to test so could get better bug
> reports
> cons - more involved, so more effort that has to be repeated if a vote
> fails
>
> Please share your thought on which method you think would be best. If
> you can think of another option that would be better, please share it.
> Also, if we pick one option and decide we don't like it, we can change
> the process for the next release.
>
> Josh
> - --
> - -------------------------------
> Josh Thompson
> Systems Programmer
> Advanced Computing | VCL Developer
> North Carolina State University
>
> Josh_Thompson@ncsu.edu
> 919-515-5323
>
> my GPG/PGP key can be found at pgp.mit.edu
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFKs+IcV/LQcNdtPQMRAjiyAJ9JxnWPwngxXrFQ3Y8nVvcMBixDkQCfV/aN
> LIwpZcuzaJrPJhW9U6gMbD0=
> =/KuR
> -----END PGP SIGNATURE-----
Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU
919.513.4571
http://vcl.ncsu.edu