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. -jg
On Mon, Mar 28, 2011 at 1:40 PM, Dhruba Borthakur <dhr...@gmail.com> wrote: > +1. I think this will be very helpful in moving the design forward quickly. > > -dhruba > > > On Mon, Mar 28, 2011 at 1:14 PM, Todd Lipcon <t...@cloudera.com> wrote: > >> Hi all, >> >> I discussed this with a couple folks over the weekend who are involved in >> 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 subtasks. >> 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 more >> manageable down the line and has a lot of operational benefits as described >> in the JIRA. The "related work" is the addition of transaction IDs to the >> 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 some >> of >> the intermediate points, various components will be temporarily broken. >> Developing on a branch will allow us to make incremental progress without >> 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 be >> another opportunity to review before the merge into trunk. This is the same >> 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 before >> merging into trunk, I would also like to propose that Ivan Kelly be granted >> 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 >
