hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-1161) need improved release process
Date Tue, 27 Mar 2007 18:24:32 GMT

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

Doug Cutting commented on HADOOP-1161:

> I'd strongly vote for a code-freeze [ ... ]

I think "code freeze" might better be called "feature freeze", or just "branch".  I agree.
 This would be ideal.  But whether we actually do this depends on whether committers are willing
to maintain two branches simultaneously.  The alternative is to simply to stall patches that
add new features until the release is complete.  At this point, we only have two active committers
(Tom & me) whose employer permits them to actually commit, and this adds to their burden.
 When we have more active committers this should become easier to manage.

> Does the 72 hour vote start when the release candidate is created?

Yes.  The release vote cannot commence until there's a signed binary to vote on.  We may have
other votes prior to that, to decide, e.g., when to branch, what patches should be applied
where, and even when it's time to build a release candidate.  But the final vote that counts,
and is required by the ASF, is for a particular set of bits, not for, e.g., a svn tag.

> I do not like the idea of applying the same patch more than one place

This also worries me.  I prefer the discipline of, when possible, applying patches once (with
a Jira bug ID in the commit message), then, in merge commit messages, including both the svn
revisions merged and the relevant Jira bug IDs.  However, this doesn't work well if there
are conflicts, and the person doing the merge isn't familiar with the patch in question. 

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

View raw message