Andrew Wang 2013-10-17, 22:01
Colin McCabe 2013-10-17, 22:07
Chris Nauroth 2013-10-18, 17:48
Colin McCabe 2013-10-18, 18:15
Chris Nauroth 2013-10-18, 20:37
Chris Nauroth 2013-10-23, 20:03
Andrew Wang 2013-10-23, 21:18
Chris Nauroth 2013-10-24, 20:45
Aaron T. Myers 2013-10-25, 06:29
I posted a comment in the other thread about feature branch merges.
My preference is to make sure the requirements we have for regular patches
be applied to feature branch patch as well (3 +1s is the only exception).
adding details about what functionality is missing (I posted a comment on
and the changes that deferred that will be done post merge to trunk would
It would be better to start the merge vote when the work is ready instead
trying to optimize 1 week by doing the required work for merging in
If all the requirements for merging have been met, I am +1 on the merge,
the need for restarting the vote.
On Thu, Oct 24, 2013 at 11:29 PM, Aaron T. Myers <[EMAIL PROTECTED]> wrote:
> I don't necessarily disagree with the general questions about the
> procedural issues of merge votes. Thanks for bringing that up in the other
> thread you mentioned. To some extent it seems like much of this has been
> based on custom, and if folks feel that more precisely defining the merge
> vote process is warranted, then I think we should take that up over on that
> With regard to this particular merge vote, I've spoken with Chris offline
> about his feelings on this. He said that he is not dead-set on restarting
> the vote, though he suspects that others may be. It seems to me the
> remaining unfinished asks (e.g. updating the design doc) can reasonably be
> done either after this vote but before the merge to trunk proper, or could
> even reasonably be done after merging to trunk.
> Given that, I'll lend my +1 to this merge. I've been reviewing the branch
> pretty consistently since work started on it, and have personally
> run/tested several builds of it along the way. I've also reviewed the
> design thoroughly. The implementation, overall design, and API seem to me
> plenty stable enough to be merged into trunk. I know that there remains a
> handful of javac warnings in the branch that aren't in trunk, but I trust
> those will be taken care of before the merge.
> If anyone out there does feel strongly that this merge vote should be
> restarted, then please speak up soon. Again, we can restart the vote if
> need be, but I honestly think we'll gain very little by doing so.
> On Fri, Oct 25, 2013 at 5:45 AM, Chris Nauroth <[EMAIL PROTECTED]
> > Hi Andrew,
> > I've come to the conclusion that I'm very confused about merge votes.
> > It's not just about HDFS-4949. I'm confused about all merge votes.
> > Rather than muddy the waters here, I've started a separate discussion on
> > common-dev.
> > I do agree with the general plan outlined here, and I will comment
> > on the HDFS-4949 jira with a binding +1 when I see that we've completed
> > that plan.
> > Chris Nauroth
> > Hortonworks
> > http://hortonworks.com/
> > On Wed, Oct 23, 2013 at 2:18 PM, Andrew Wang <[EMAIL PROTECTED]
> > >wrote:
> > > Hey Chris,
> > >
> > > Right now we're on track to have all of those things done by tomorrow.
> > > Since the remaining issues are either not technical or do not involve
> > major
> > > changes, I was hoping we could +1 this merge vote in the spirit of "+1
> > > pending jenkins". We've gotten clean unit test runs on upstream Jenkins
> > as
> > > well, so the only fixups we should need for test-patch.sh are findbugs
> > and
> > > javac (which are normally pretty trivial to clean up). Of course, all
> > > your listed prereqs and test-patch would be taken care of before
> > > merging to trunk.
> > >
> > > So, we can reset the vote if you feel strongly about this, but it seems
> > > like the only real result will be delaying the merge by a week.
> > >
> > > Thanks,
> > > Andrew
> > >
> > >
> > > On Wed, Oct 23, 2013 at 1:03 PM, Chris Nauroth <
> [EMAIL PROTECTED]
> > > >wrote:
> > >
> > > > I've received some feedback that we haven't handled this merge vote
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Chris Nauroth 2013-10-25, 16:51
Colin McCabe 2013-10-24, 23:02
Aaron T. Myers 2013-10-24, 20:32