hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dhruba Borthakur <dhr...@gmail.com>
Subject Re: HDFS-1623 branching strategy
Date Fri, 08 Jul 2011 07:04:30 GMT
+1, this sounds like a very good approach.

-dhruba

On Thu, Jul 7, 2011 at 4:33 PM, Eli Collins <eli@cloudera.com> wrote:

> +1
>
> Sounds like this has worked well for the MR2 branch as well.
>
> Thanks for volunteering to maintain the branch.
>
> On Thu, Jul 7, 2011 at 1:43 PM, Aaron T. Myers <atm@cloudera.com> wrote:
> > Hello everyone,
> >
> > This has been informally mentioned before, but I think it's best to be
> > completely transparent/explicit about this.
> >
> > We (Sanjay, Suresh, Todd, Eli, myself, and anyone else who wants to help)
> > intend to do the work for HDFS-1623 (High Availability Framework for HDFS
> > NN) on a development branch off of trunk. The work in the HDFS-1073
> > development branch is necessary to complete HDFS-1623. As such, we're
> > waiting for the work in HDFS-1073 to be merged into trunk before creating
> a
> > branch for HDFS-1623.
> >
> > Once this branch is created, I'd like to use a similar modified
> > commit-then-review policy for this branch as was done in the HDFS-1073
> > branch, which I think worked very well. To review, this was:
> >
> > {quote}
> > - A patch will be uploaded to the JIRA for review like usual
> > - If another committer provides a +1, it may be committed at that
> > point, just like usual.
> > - If no committer provides +1 (or a review asking for changes) within
> > 24 business hours, it will be committed to the branch under "commit then
> > review" policy.Of course if any committer feels that code needs to be
> > amended, he or she should feel free to open a new JIRA against the branch
> > including the review comments, and they will be addressed before the
> merge
> > into trunk. And just like with any branch merge, ample time will be given
> > for the community to review both the large merge commit as well as the
> > individual historical commits of the branch, before it goes into trunk.
> > {quote}
> >
> > I'm also volunteering to keep the HDFS-1623 development branch up to date
> > with respect to merging the concurrent changes which go into trunk into
> this
> > development branch to make sure the merge back into trunk is as painless
> as
> > possible.
> >
> > Comments are certainly welcome on this strategy.
> >
> > Thanks a lot,
> > Aaron
> >
> > --
> > Aaron T. Myers
> >  Software Engineer, Cloudera
> >
>



-- 
Connect to me at http://www.facebook.com/dhruba

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message