On 14/12/2006, at 10:46 AM, Joakim Erdfelt wrote:
* If unanimous +1 vote by 7 or more PMC members, then release
can occur before 72 hour window is up.
Don't really understand the rush, or the arbitrary number 7 (yes, it
is the number of perfection, but other than that, it has no
significance in a growing PMC of 18 and is far more than the required
3 :). A flat 3 days is far simpler, and if we are executing better on
our releases it should be no real barrier. It also gives the
important time for people to change their votes if someone else
highlights something wrong.
I'm not adverse to emergency releases either - if they are designated
as such they only require the 3 PMC members to vote (though more is
better, and it must be exceptional circumstances - I'd generally
prefer to just pull the previous one if there was something that wrong).
e) Age of development version (days since last non-snapshot
release)
is this necessary? I think it's a generally useful thing to know, but
probably more when one is neglected, not when it is about to be released
f) Downstream snapshot dependencies that might cause problems.
There must be none when it comes to be voted on. It should be ready
to pull the trigger.
f) Tasks that have been completed in SCM but do not appear
in the
Jira completion list.
I don't think we should encourage this. Just put it in JIRA.
g) URL to jira completion report for this version.
Is this needed if they have been pasted into the email?
* If a change occurs to the project, the vote should be updated
with the change and a new vote started. (this resets the 72
hours)
This only consitutes changes that occur in the project itself,
not downstream dependencies.
Agreed, but the downstream dependencies changing will either not be
part of the release, or cause the project to update to a new snapshot
that does constitute a change, so I don't see that the statement adds
anything.
[snip agreed on rules]
For these rules, can we incorporate the use of RAT? http://
code.google.com/p/arat/
See also stuff Commons were shopping for last time I started
discussing this:
* http://wiki.apache.org/jakarta-commons/ReleaseChecking
* http://wiki.apache.org/jakarta-commons/ReleaseShoppingList
It goes like this...
a) Call vote
I think this is (e) since it requires steps from b, c, c, d.
BTW, I think voting on binaries + source is a Good Thing (TM), but if
we expect this to be adopted widely, we need to be flexible enough to
allow production of just the source tag to vote on as well. I think
all this can be done via phases in the release plugin (with increased
support for resuming later), and then being able to turn some on/off
(or doing binding of some sort, like the build lifecycle).
* Generate 'need to bless', email to mailing list about
staged artifacts and site.
Agree, as a template, not an automated mail.
* Send email announcing (to announce@ mailing lists) the
release.
- Include links to artifacts on real repository.
- Include changelog
I think again, this should be a template to help rather than be
automated.
maven-release-staging-plugin (not written)
This could be useful to bundle up the various other plugins
into an
simple goal. possible goals :prepare, :stage, :bless. This
plugin
could also ensure the configuration parameters needed in the
settings.xml
file to perform a release.
Does it need a separate plugin? I think this is just an extra
workflow in the main release process. You'll want to think about this
in terms of how it can be triggered inside Continuum as well...
maven-apache-deploy-check-plugin (not written)
I think this is where RAT could come in.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
