hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tahir Hashmi (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-1161) need improved release process
Date Wed, 28 Mar 2007 09:07:32 GMT

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

Tahir Hashmi commented on HADOOP-1161:
--------------------------------------

> * Use trunk for main development.
> * Create a branch for each major release.
> * Apply changes to trunk first, then backport into branches later. 

+1

I've worked with a project following these conventions and it worked out well for us. The
way we handled back-porting was as follows:

1. decide whether the issue needs back-porting and how far it goes
2. the owner of the issue creates separate patches for trunk and maintenance branches
3. both patches are peer reviewed

Deciding what to back-port was based on issue severity and we only back-ported critical stuff
for which there were no work-arounds. We rarely ever back-ported to releases before the one
currently under maintenance.

Step 2 appears to be burdensome on contributors but in practice isn't so great an issue. It
also works well in cases where the contributors out-number commiters since contributors have
the best knowledge of how to resolve conflicts for their patch.

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


Mime
View raw message