+1 for creating a branch.
Agree with Jakob this should not mean less intensive reviewing.
On Mon, Mar 28, 2011 at 4:39 PM, Jakob Homan <[EMAIL PROTECTED]> wrote:
> Doing this work on a branch makes sense. +1.
> However, the patches that have been committed so far required
> extensive review and revision, and in one case, an addendum patch.
> Additionally, the patches in related JIRAs such as HDFS-1557 and
> HDFS-1572 have required multiple revisions and corrections. While
> it's up to each committer which +1 they're willing to accept, I don't
> see any harm in keeping our current standards for review, considering
> the importance and difficulty of this work. In fact, since moving the
> work to a branch will also move it off of many reviewers' radar, it
> may even be reasonable to increase the scrutiny. Reviewing giant
> branch merges is difficult and, I believe, more error-prone than
> reviewing smaller packets of work. So far these patches have received
> timely reviews, if this does not turn out to be the case, let other
> committers know so we can do our part.
> On Mon, Mar 28, 2011 at 1:40 PM, Dhruba Borthakur <[EMAIL PROTECTED]>
> > +1. I think this will be very helpful in moving the design forward
> > -dhruba
> > On Mon, Mar 28, 2011 at 1:14 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> >> Hi all,
> >> I discussed this with a couple folks over the weekend who are involved
> >> the project, but wanted to let the dev community at large know:
> >> I'm planning on creating a new SVN branch for HDFS-1073 and its
> >> For those not aware, HDFS-1073 is a rethinking of how the NN, 2NN, and
> >> BackupNode store images and edit logs on disk. This will help make HA
> >> manageable down the line and has a lot of operational benefits as
> >> in the JIRA. The "related work" is the addition of transaction IDs to
> >> persistent storage of the NN, and some refactoring in the edit log
> >> subsystem.
> >> The reasoning behind creating a branch is that, since this is a fairly
> >> large
> >> change, it is easier to develop through a number of subtasks. But at
> >> of
> >> the intermediate points, various components will be temporarily broken.
> >> Developing on a branch will allow us to make incremental progress
> >> worrying about keeping all tests green after every change. We will of
> >> course
> >> make sure all tests pass before merging back into trunk. There will also
> >> another opportunity to review before the merge into trunk. This is the
> >> development methodology as was done for the 0.21 Append work and is now
> >> being used for Federation.
> >> Given that there will be another opportunity to review these changes
> >> merging into trunk, I would also like to propose that Ivan Kelly be
> >> the ability to "+1" patches on this branch despite not being an HDFS
> >> committer. Ivan is actively contributing on this project and understands
> >> the
> >> code well.
> >> Unless there are any objections, I will create this branch and an
> >> associated
> >> Fix Version on JIRA tonight.
> >> Thanks!
> >> -Todd
> >> --
> >> Todd Lipcon
> >> Software Engineer, Cloudera
> > --
> > Connect to me at http://www.facebook.com/dhruba