Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HDFS >> mail # dev >> Re: [VOTE] Merge HDFS-3077 (QuorumJournalManager) branch to trunk

Copy link to this message
Re: [VOTE] Merge HDFS-3077 (QuorumJournalManager) branch to trunk
Sanjay, Suresh,

I don't think we should block the merge on discussion about parts of
the design. It's great that you guys are coming up to speed on the
design and have feedback. We're confident the feedback can be
addressed in follow-on jiras (just as federation and HA have been
iterated on after merging).  Todd has maintained the 3077 branch for
months, continuously updated the design doc, addressed questions
promptly, given sufficient heads up, and even even delayed the merge
per your request.  If you have specific technical objections with the
merge patch you should raise them, otherwise we're going to merge it
and iterate on the feedback in the jira with follow on patches.

On Mon, Oct 1, 2012 at 10:55 AM, sanjay Radia <[EMAIL PROTECTED]> wrote:
> Todd,
>   Even though this work was under development over a period of time,  during its development it was not clear when the design was fairly stable to begin a thorough review. Hence the time of merge is when the real review happens in such large projects.
> I have already indicated on the jira that i do not have any philosophical objection to this work being in HDFS - hence this should not be a worry on your part.
> The extra week will result in a more through review (hopefully this will have a side effect of perhaps easing Konstanine's concern about
> HDFS adding such complex code).
> Lets plan to do the merge next monday.
> thanks
> sanjay
> On Sep 28, 2012, at 3:02 PM, Todd Lipcon wrote:
>> Hey Sanjay,
>> While I understand it's substantial and complex code, the code and the
>> design doc have been available for several months, and the community
>> has certainly been aware of its development. I also gave a heads up
>> last week that I would call a merge this week. So I feel like there
>> has been sufficient time for interested parties to review.
>> That said, since I was sick for much of this week and not immediately
>> responsive to some of the questions from you and Suresh, I'm happy to
>> agree to postpone the merge to early next week. Let's extend the vote
>> to last until Monday end of day PST.
>> Of course if there are follow-up questions or bugs found after the
>> merge, you've all got my phone number and I'm not going anywhere! ;-)
>> Thanks
>> -Todd
>> On Fri, Sep 28, 2012 at 12:06 PM, sanjay Radia <[EMAIL PROTECTED]> wrote:
>>> Suresh and I are still reviewing this design and patch.
>>> The 3077 code along with  the code pulled from 3092 is fairly substrantial. The design is also fairly complex and involved.
>>> I  would request that we postpone the merge for another week to give folks time to review this fully.
>>> sanjay
>>> On Sep 25, 2012, at 4:02 PM, Todd Lipcon wrote:
>>>> Dear fellow HDFS developers,
>>>> Per my email thread last week ("Heads up: merge for QJM branch soon"
>>>> at http://markmail.org/message/vkyh5culdsuxdb6t) I would like to
>>>> propose merging the HDFS-3077 branch into trunk. The branch has been
>>>> active since mid July and has stabilized significantly over the last
>>>> two months. It has passed the full test suite, findbugs, and release
>>>> audit, and I think it's ready to merge at this point.
>>>> The branch has been fully developed using the standard
>>>> 'review-then-commit' (RTC) policy, and the design is described in
>>>> detail in a document attached to HDFS-3077 itself. The code itself has
>>>> been contributed by me, Aaron, and Eli, but I'd be remiss not to also
>>>> acknowledge the contributions to the design from discussions with
>>>> Suresh, Sanjay, Henry Robinson, Patrick Hunt, Ivan Kelly, Andrew
>>>> Purtell, Flavio Junqueira, Ben Reed, Nicholas, Bikas, Brandon, and
>>>> others. Additionally, special thanks to Andrew Purtell and Stephen Chu
>>>> for their help with cluster testing.
>>>> This initial VOTE is to merge only into trunk, but, following the
>>>> pattern of automatic failover, I expect to merge it into branch-2