[
https://issues.apache.org/jira/browse/HADOOP-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484221
]
Doug Cutting commented on HADOOP-1161:
--------------------------------------
> +1 for branching. I haven't seen any large project without branches.
We already do have a branch for each major release. The question is where we
first commit patches and how to migrate them between branches. To date we've
mostly first committed patches to trunk and selectively merged them to the
branches prior to releases. This simplifies things, as it reduces the
possibility of conflicts during merges, while keeping the option open of doing
more complicated things, e.g., applying different patches to the trunk and to a
branch. But we could instead, e.g., commit each patch separately to both the
branch and to the trunk, or we could commit patches only to the branch, and
then merge them to trunk. But we need some discipline, both to minimize merge
conflicts, and to ensure that patches make it into the trunk. Can someone
propose a reasonable system?
> 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.
