hadoop-common-dev mailing list archives

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

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

Arun C Murthy commented on HADOOP-1161:
---------------------------------------

In general I like the two-month cycle and clearly it's time for more elaborate branching/merging...
so a big +1.

W.r.t to improved releases IMO the biggest bang for the buck would come from significantly
better testing on large-clusters prior to releases. To that effect I'd strongly vote for a
code-freeze (atleast 2wks for a 1-month releases and 3wks for 2-month releases). This would
help 'soak-in' the features/fixes and generally foster much better confidence in the releases.

Given the nature of the project i.e. large-scale etc. I'd not be very confident of just 'ant
test' since it's clearly very hard to achieve reasonable code-coverage (clearly we could do
better here too with more junit tests etc.) and also to simulate the 'large-scale' part in
test-suites on single-nodes. Hence I'd be much more confident with a code-freeze and a reasonable
amount of regressions/benchmarks run on large-clusters.

Here is something along the lines of what I think would help:

1. Lets say we 0.15.0 target a release for Jan 1
2. We have a code-freeze (i.e. no new features henceforth) on Dec 15 (or Dec 10, earlier the
better).
3. We release an early 0.15.0-rc1 (release candidate) on Dec15
4. We let Nigel and the test-suites/benchmarks loose on 0.15.0-rc1. 
5. If we fix enough bugs and are reasonably confident we can release a 0.15.0-rc2 a week or
so later (Dec 22).
6. Continue testing (i.e. test-suites and benchmarks) on 0.15.0-rc2 for *atleast a week*.
7. Release more rcs (0.15.0-rc3, 0.15.0-rc4 etc.) if warranted (criticality of bug etc.)
8. Finally promote the 'last-known' rc to 0.15.0

Rinse and repeat for 0.15.1 (only bug-fixes of course), while we continue checking-in new
features into 0.16.0 branch.

-*-*-

Thoughts?

> 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