[ 
https://issues.apache.org/jira/browse/HADOOP-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489864
 ] 

Nigel Daley commented on HADOOP-1161:
-------------------------------------

To summarize, I think we've roughly agreed to the following dev and release 
process (bullet numbers are for reference purposes is remaining discussion):

Development:
1) use trunk for main development
2) patches must not mix bug fixes and enhancements

Major Releases:
3) major releases every two months on the first Friday, provided release X-1 
has reached stability
4) 2 weeks before the targeted release date:
   a) create a release branch
   b) feature freeze the branch
   c) bug fixes are applied to trunk first, then backported into the release 
branch
5) when the release branch seems stable, a release candidate is created 
   a) release candidate builds should be placed in 
lucene.apache.org/hadoop/dev/dist 
   b) release candidates should be accompanied by a md5 and pgp signatures 
6) 72-hours before the targeted release date, a vote on the release candidate 
is explicitly called for on hadoop-dev 
   a) 3 binding +1 votes and a majority are required 
   b) if the vote passes, the release can then posted to 
www.apache.org/dist/lucene/hadoop for mirroring 

A couple questions:
- Do you agree with my summary?
- In 5, how do we agree on 'stable'? call a vote?
- In 3, what happens if release X-1 isn't stable? leave it unspecified?
- In 6b, what if the vote doesn't pass? leave it unspecified?



> need improved release process
> -----------------------------
>
>                 Key: HADOOP-1161
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1161
>             Project: Hadoop
>          Issue Type: Improvement
>          Components: build
>            Reporter: Doug Cutting
>             Fix For: 0.13.0
>
>
> Hadoop's release process needs improvement.  We should better ensure that 
> releases are stable, not releasing versions that have not been proven stable 
> on large clusters, and we should better observe Apache's release procedures.  
> Once agreed on, this process should be documented in 
> http://wiki.apache.org/lucene-hadoop/HowToRelease.
> Here's a proposal:
> . candidate release builds should be placed in 
> lucene.apache.org/hadoop/dev/dist
> . candidate artifacts should be accompanied by a md5 and pgp signatures
> . a 72-hour vote for the release artifact should be called on hadoop-dev.
> . 3 binding +1 votes and a majority are required
> . if the vote passes, the release can then posted to 
> www.apache.org/dist/lucene/hadoop for mirroring
> This would bring us into accord with Apache's requirements, and better permit 
> large-cluster validation.
> We should also build consensus for a release before we commence this process. 
>  Perhaps we should aim for releases every two months instead of every month.  
> We should perhaps develop more elaborate branching and merging conventions 
> around releases.  Currently we mostly lock-out changes intended for release 
> X+1 from trunk until release X is complete, which can be awkward.  How can we 
> better manage that?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to