hadoop-common-dev mailing list archives

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

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

James P. White commented on HADOOP-1161:
----------------------------------------

>> I do not like the idea of applying the same patch more than one place (i.e trunk
and a branch etc.) -
>> merging handles this nicely, provided we maintain a bit of discipline.
>
>Merging is fine, but it means you have to commit in one place and then start the next.
If there is a conflict, it would be nice to know >before you commit it.
>
>In my experience, it works much better to merge changes from the stable branch up into
the head. The problem with merging down is
>that you can have accidental leakage of new features into the stable branch.

Merging is bad for just that reason.  Patches to release branches should be applied one-at-a-time
by the release maintainer.  Fixes/features to the trunk occur willy-nilly in comparison to
the care that must be exercised on a release branch for a stable product.  

With simple changes that have no conflict, the branch maintainer simply applies the patch.
 Where the change is more extensive, then more work must be done.  But it certainly makes
no sense for such a complex change to be made to the release branch until that big of a change
is fully vetted in the trunk.  If someone knows in advance they're making a big change that
will result in conflicts (that is the trunk of the affected files has already diverged greatly
from the release and the big change is going to go into the release - which doesn't really
make sense since release branch changes should usually just be bug fixes), the change should
be made on it's own branch from the point of divergence.

The double maintenance is unavoidable because the changes are made by people in very different
roles ("feature developer" vs. "release maintainer").  The difference is hard to see in a
smallish project where the same person is doing both jobs, but is important in the context
of this issue ("improved release process").


> 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