You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by Chris Nauroth <cn...@hortonworks.com> on 2013/10/24 22:40:58 UTC
[DISCUSS] What is the purpose of merge vote threads?
I've realized that I'm very confused about the purpose and the process of
merge votes. I'd like to use this thread for clarification so that we all
know exactly what our votes on a merge thread mean. It's possible that
we'll even want to reconsider whether or not merge vote threads are useful.
>From what I can tell, there is no concrete action taken as a result of a
merge vote thread. If the vote passes, nothing happens. If the vote
doesn't pass, nothing happens. Instead, it is the +1 vote on the merge
patch in jira that really drives action. This differs from all other
voting topics, which do result in some concrete action if passed (new
release, change to the bylaws, etc.). Considering that, what value do we
get from merge vote threads?
It seems the merge votes could be replaced entirely by the traditional code
review and commit process. Committers can respond directly on the umbrella
jira with +1 (or -1 and a list of what needs to be done to earn a +1). The
merge vote threads may in fact be detrimental, because they fork relevant
technical discussion away from the jira and into the mailing lists. Would
it be appropriate for us to say that the real merge vote happens on the
jira and do away with the process of conducting a separate vote on the
mailing list?
Also, I don't see consistency in this process across sub-projects. Merge
vote threads have been more frequent in HDFS than YARN. If we continue to
use merge vote threads, then do we need to do this consistently across the
sub-projects?
My first inclination was to review the bylaws for clarification. The
bylaws don't call out merges as a separate voting topic. Instead, merges
just fall under Code Change with the extra requirement of 3 +1s from
committers instead of 1. Again, this sounds like activity better suited to
the jira in question, where the proposed action is to commit a code change,
and committers and contributors enter comments to vote on acceptance of the
code and related artifacts like design docs and test plans.
Of course, there may be a need to announce that a big feature is almost
ready and needs more reviewers. That could be handled by an email to the
dev lists, but I don't see the benefit of labeling that as a vote. Best
case scenario, the vote is redundant with the more meaningful activity
happening on the jira. Worst case scenario, the vote is a distraction and
introduces an artificial 7-day delay on code that has already received
votes in jira.
Until I get some clarification on this, I don't think I can participate in
further merge vote threads in good conscience. I'll continue to offer my
+1 or -1 directly on feature jiras, where I know with certainty that I'm
voting on whether or not to accept something tangible.
Thank you!
Chris Nauroth
Hortonworks
http://hortonworks.com/
--
CONFIDENTIALITY NOTICE
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.
Re: [DISCUSS] What is the purpose of merge vote threads?
Posted by "Aaron T. Myers" <at...@apache.org>.
On Thu, Oct 24, 2013 at 3:46 PM, Doug Cutting <cu...@apache.org> wrote:
> Here's my take, FWIW. The entire project needs to determine whether
> it is willing to take on the maintenance of code developed in a
> branch. This vote needs the widest audience. On the other hand,
> discussion on the umbrella Jira for the branch concerns the precise
> details of the merge commit. Even if the project is generally willing
> to accept maintenance of the code in a branch, committing it should
> not break the build that day. So fine-tuning the precise details of
> the merge often happens in Jira rather than as a part of the formal
> merge vote. Sometimes these are determined in parallel.
>
> Since a -1 must always be accompanied by a rationale, it should be
> clear whether such a vote concerns a fine point of the specific patch
> that's easily corrected or whether it's about a fundamental problem
> with the branch that will take longer to address. Either sort might
> be cast in either place. A fine-point objection shouldn't reset
> voting clocks and a fundamental objection concerns things that cannot
> be fixed in a voting window. If something lies in the middle then
> should be discussion until consensus is reached about whether the
> merge date need be delayed, voting restarted later, etc. I don't see
> a need for a more rigid policy here since we haven't seen things
> running amok around branch merges due to a lack of policy.
>
> Is that consistent with other folks understanding?
>
+1, I agree with all of this, and this is how I've always understood the
merge vote process myself.
Best,
Aaron
Re: [DISCUSS] What is the purpose of merge vote threads?
Posted by Chris Nauroth <cn...@hortonworks.com>.
Thank you to everyone who replied. Even though it sounds like there is not
complete consensus on some of the finer points, I think I have a clearer
understanding on how to participate now.
I do think posting all requirements in jira before calling the merge vote
makes the process more effective. Contributors who haven't been following
the branch closely can get up to speed quickly by reading a refreshed
design doc and test plan. Getting a +1 from Jenkins before the vote helps
reviewers focus on the logic instead of problems that could be caught by
static analysis.
Chris Nauroth
Hortonworks
http://hortonworks.com/
On Fri, Oct 25, 2013 at 12:04 PM, Doug Cutting <cu...@apache.org> wrote:
> On Fri, Oct 25, 2013 at 10:56 AM, Vinod Kumar Vavilapalli
> <vi...@apache.org> wrote:
> > Discussing on a voting thread is not productive.
>
> When all votes are +1 then no discussion is needed. One shouldn't
> call a vote unless one expects all votes to be +1. But, if
> unexpectedly they're not all +1, then a discussion must ensue, to
> substantiate the veto and to try to establish a remedy.
>
> It seems overly formal to immediately terminate all votes at the first
> expression of concern, restarting them later. That puts process ahead
> of practicality and progress. Rather, if an unforeseen yet easily
> addressed concern is raised during a vote then folks might reasonably
> agree to continue without restarting the vote.
>
> The purpose of the vote is to establish consensus. If consensus is
> determined, then there's no need to delay. So a vote can pass when
> the -1 voters change their vote to +1. This might not hold if a
> remedy might be considered controversial, and its inclusion might
> reasonably invalidate prior +1 votes. Then more time might be given
> for folks to consider the remedy. But when the remedy is trivial it
> needn't be held to higher voting standard than a regular patch.
>
> Commits differ from releases since a release cannot be easily altered
> once published. However a commit can be amended by subsequent
> commits. We certainly want to minimize the need for subsequent
> commits, but don't need the same level of confidence. With branch
> merge votes we should focus on the issue of whether the project is
> ready to assume the burden of maintaining the new functionality, since
> it's much harder to remove things than add them. That's the reason
> for the one-week, 3 +1 rule. For minor issues like compiler warnings,
> a fix to a merge patch should be held to the same standard as any
> other patch.
>
> Doug
>
--
CONFIDENTIALITY NOTICE
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.
Re: [DISCUSS] What is the purpose of merge vote threads?
Posted by Doug Cutting <cu...@apache.org>.
On Fri, Oct 25, 2013 at 10:56 AM, Vinod Kumar Vavilapalli
<vi...@apache.org> wrote:
> Discussing on a voting thread is not productive.
When all votes are +1 then no discussion is needed. One shouldn't
call a vote unless one expects all votes to be +1. But, if
unexpectedly they're not all +1, then a discussion must ensue, to
substantiate the veto and to try to establish a remedy.
It seems overly formal to immediately terminate all votes at the first
expression of concern, restarting them later. That puts process ahead
of practicality and progress. Rather, if an unforeseen yet easily
addressed concern is raised during a vote then folks might reasonably
agree to continue without restarting the vote.
The purpose of the vote is to establish consensus. If consensus is
determined, then there's no need to delay. So a vote can pass when
the -1 voters change their vote to +1. This might not hold if a
remedy might be considered controversial, and its inclusion might
reasonably invalidate prior +1 votes. Then more time might be given
for folks to consider the remedy. But when the remedy is trivial it
needn't be held to higher voting standard than a regular patch.
Commits differ from releases since a release cannot be easily altered
once published. However a commit can be amended by subsequent
commits. We certainly want to minimize the need for subsequent
commits, but don't need the same level of confidence. With branch
merge votes we should focus on the issue of whether the project is
ready to assume the burden of maintaining the new functionality, since
it's much harder to remove things than add them. That's the reason
for the one-week, 3 +1 rule. For minor issues like compiler warnings,
a fix to a merge patch should be held to the same standard as any
other patch.
Doug
Re: [DISCUSS] What is the purpose of merge vote threads?
Posted by Vinod Kumar Vavilapalli <vi...@apache.org>.
It seems that overall the branch-merge voting threads are overloaded with multiple goals.
Like other things that we vote on, a DISCUSS/PROPOSAL thread upfront for the branch-merge should alleviate any concerns that any committer might have. Once that is done, [VOTE] thread can simply be a formality of running tests, commiter +1s etc.
Discussing on a voting thread is not productive.
Thanks,
+Vinod
On Oct 25, 2013, at 10:18 AM, Doug Cutting wrote:
> On Fri, Oct 25, 2013 at 9:35 AM, Suresh Srinivas <su...@hortonworks.com> wrote:
>> Granted some of the feature readiness activity can be done during voting.
>> But I fail to understand why expediting a feature that takes months to build
>> should try to optimize a week. Why not finish the requirements we have for
>> every patch for feature branch also?
>
> I agree that requirements should not be relaxed. But different clocks
> can be used for different kinds of concerns. For example, compiler
> warnings should be addressed before commit but probably shouldn't
> require restarting a week-long vote. The point of the week is to give
> folks ample time to review a patch. Once concerns raised are
> addressed to the satisfaction of those who've raised them why would
> more time be required? However if someone asks for more time to
> review because the changes they requested are not easily reviewable in
> the time remaining then they should be given that time. Lastly, if
> syncing a branch with trunk is difficult as trunk changes, then there
> may be costs to delaying and we shouldn't delay without reason.
>
> Doug
--
CONFIDENTIALITY NOTICE
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.
Re: [DISCUSS] What is the purpose of merge vote threads?
Posted by Doug Cutting <cu...@apache.org>.
On Fri, Oct 25, 2013 at 9:35 AM, Suresh Srinivas <su...@hortonworks.com> wrote:
> Granted some of the feature readiness activity can be done during voting.
> But I fail to understand why expediting a feature that takes months to build
> should try to optimize a week. Why not finish the requirements we have for
> every patch for feature branch also?
I agree that requirements should not be relaxed. But different clocks
can be used for different kinds of concerns. For example, compiler
warnings should be addressed before commit but probably shouldn't
require restarting a week-long vote. The point of the week is to give
folks ample time to review a patch. Once concerns raised are
addressed to the satisfaction of those who've raised them why would
more time be required? However if someone asks for more time to
review because the changes they requested are not easily reviewable in
the time remaining then they should be given that time. Lastly, if
syncing a branch with trunk is difficult as trunk changes, then there
may be costs to delaying and we shouldn't delay without reason.
Doug
Re: [DISCUSS] What is the purpose of merge vote threads?
Posted by Suresh Srinivas <su...@hortonworks.com>.
I agree with what Nicholas is saying.
Feature branch merge votes are similar to traditional review-commit process.
That means the code should be ready, and pass the Jenkins build tests.
Also similar to regular patches where one describes what changes the
patch brings, having an updated design document (with change history
for the updates made to the design) helps people understand the design.
Updated user document for the feature helps end users to understand how the
feature works and helps them participate in testing. Finally, as expected
by every patch, we should have unit tests and also details of manual tests
done (with test plan for a feature).
This helps people participate in the voting/review more effectively.
There can be exceptions to the above list and some of the work could be
deferred. That could be captured in the jira, with the plan of how that
work gets done later. In such cases in the past we had
deferred merging the feature from trunk to a release branch until the work
was completed in trunk.
Granted some of the feature readiness activity can be done during voting.
But I fail to understand why expediting a feature that takes months to build
should try to optimize a week. Why not finish the requirements we have for
every patch for feature branch also?
On Thu, Oct 24, 2013 at 6:19 PM, Tsz Wo (Nicholas), Sze <
s29752-hadoopdev@yahoo.com> wrote:
> (Resend)
>
> No. In the past, committers would merge a branch once the merge vote had
> been passed even there were problems in the branch. Below is my
> understanding of merge vote.
>
> Feature branch merge votes is the same as the traditional code
> review-commit process except that it requires three +1's and it happens in
> the mailing list. For review-commit, we +1 on the patch. If we think that
> the patch needs to be changed, we should ask the contributor posting a new
> patch before +1. This is not strictly enforced. In some cases, committers
> may say something like "+1 once X and Y have been fixed". In some worse
> cases, a committer may has committed a patch without +1 and then his friend
> committer will say "I mean +1 by my previous comment but I forgot to post
> it. Sorry, here is my +1."
>
> For merge vote, it should be considered that a big patch is generated by
> the diff from the branch over trunk. Then, committers vote on the big
> patch in the mailing list. As review-commit, if the patch need to be
> changed, committers should not +1 on it. Unfortunately, it is generally
> hard to review big patches and it is relatively easy to sneak bad code in.
>
> Both review-commit and merge vote are similar to voting on release
> candidates -- we vote on the bits of the candidate but neither vote on an
> idea nor a plan. (Of course, there are other types of vote for voting on a
> plan.)
>
> Regards,
> Tsz-Wo
>
>
>
>
> > On Thursday, October 24, 2013 5:09 PM, Tsz Wo Sze <sz...@yahoo.com>
> wrote:
> > > No. In the past, committers would merge a branch once the merge vote
> had been
> > passed even there were problems in the branch. Below is my
> understanding of
> > merge vote.
> >
> > Feature branch merge votes is the same as the traditional code
> > review-commit process except that it requires three +1's and it happens
> in
> > the mailing list. For review-commit, we +1 on the patch. If we think
> > that the patch needs to be changed, we should ask the contributor
> > posting a new patch before +1. This is not strictly enforced. In some
> > cases, committers may say something like "+1 once X and Y have been
> > fixed". In some worse cases, a committer may has committed a patch
> > without +1 and then his friend committer will say "I mean +1 by my
> > previous comment but I forgot to post it. Sorry, here is my +1."
> >
> > For merge vote, it should be considered that a big patch is
> > generated by the diff from the branch over trunk. Then, committers vote
> on
> > the big patch in the mailing list. As review-commit, if the patch need
> to be
> > changed,
> > committers should not +1 on it. Unfortunately, it is generally hard to
> > review big patches and it is relatively easy to sneak bad code in.
> >
> >
> > Both review-commit and merge vote are similar to voting
> > on release candidates -- we vote on the bits of the candidate but
> neither vote
> > on an idea nor a plan. (Of course, there are other types of vote for
> voting on
> > a plan.)
> >
> > Regards,
> > Tsz-Wo
> >
> >
> >
> >
> >> On Thursday, October 24, 2013 3:46 PM, Doug Cutting
> > <cu...@apache.org> wrote:
> >> > On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth
> > <cn...@hortonworks.com>
> >> wrote:
> >>
> >>> When the voting happens on jira with a finalized merge patch, I know
> >>> exactly what I'm voting for, because it's the same
> >> review-and-commit
> >>> process that we follow every day with the extra requirement of 3
> +1s.
> > When
> >>> it happens on email, it's less clear to me exactly what I'm
> > voting
> >> for.
> >>
> >> Here's my take, FWIW. The entire project needs to determine whether
> >> it is willing to take on the maintenance of code developed in a
> >> branch. This vote needs the widest audience. On the other hand,
> >> discussion on the umbrella Jira for the branch concerns the precise
> >> details of the merge commit. Even if the project is generally willing
> >> to accept maintenance of the code in a branch, committing it should
> >> not break the build that day. So fine-tuning the precise details of
> >> the merge often happens in Jira rather than as a part of the formal
> >> merge vote. Sometimes these are determined in parallel.
> >>
> >> Since a -1 must always be accompanied by a rationale, it should be
> >> clear whether such a vote concerns a fine point of the specific patch
> >> that's easily corrected or whether it's about a fundamental problem
> >> with the branch that will take longer to address. Either sort might
> >> be cast in either place. A fine-point objection shouldn't reset
> >> voting clocks and a fundamental objection concerns things that cannot
> >> be fixed in a voting window. If something lies in the middle then
> >> should be discussion until consensus is reached about whether the
> >> merge date need be delayed, voting restarted later, etc. I don't see
> >> a need for a more rigid policy here since we haven't seen things
> >> running amok around branch merges due to a lack of policy.
> >>
> >> Is that consistent with other folks understanding?
> >>
> >> Doug
> >>
> >
>
--
http://hortonworks.com/download/
--
CONFIDENTIALITY NOTICE
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.
Re: [DISCUSS] What is the purpose of merge vote threads?
Posted by "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>.
(Resend)
No. In the past, committers would merge a branch once the merge vote had been passed even there were problems in the branch. Below is my understanding of merge vote.
Feature branch merge votes is the same as the traditional code review-commit process except that it requires three +1's and it happens in the mailing list. For review-commit, we +1 on the patch. If we think that the patch needs to be changed, we should ask the contributor posting a new patch before +1. This is not strictly enforced. In some cases, committers may say something like "+1 once X and Y have been fixed". In some worse cases, a committer may has committed a patch without +1 and then his friend committer will say "I mean +1 by my previous comment but I forgot to post it. Sorry, here is my +1."
For merge vote, it should be considered that a big patch is generated by the diff from the branch over trunk. Then, committers vote on the big patch in the mailing list. As review-commit, if the patch need to be changed, committers should not +1 on it. Unfortunately, it is generally hard to review big patches and it is relatively easy to sneak bad code in.
Both review-commit and merge vote are similar to voting on release candidates -- we vote on the bits of the candidate but neither vote on an idea nor a plan. (Of course, there are other types of vote for voting on a plan.)
Regards,
Tsz-Wo
> On Thursday, October 24, 2013 5:09 PM, Tsz Wo Sze <sz...@yahoo.com> wrote:
> > No. In the past, committers would merge a branch once the merge vote had been
> passed even there were problems in the branch. Below is my understanding of
> merge vote.
>
> Feature branch merge votes is the same as the traditional code
> review-commit process except that it requires three +1's and it happens in
> the mailing list. For review-commit, we +1 on the patch. If we think
> that the patch needs to be changed, we should ask the contributor
> posting a new patch before +1. This is not strictly enforced. In some
> cases, committers may say something like "+1 once X and Y have been
> fixed". In some worse cases, a committer may has committed a patch
> without +1 and then his friend committer will say "I mean +1 by my
> previous comment but I forgot to post it. Sorry, here is my +1."
>
> For merge vote, it should be considered that a big patch is
> generated by the diff from the branch over trunk. Then, committers vote on
> the big patch in the mailing list. As review-commit, if the patch need to be
> changed,
> committers should not +1 on it. Unfortunately, it is generally hard to
> review big patches and it is relatively easy to sneak bad code in.
>
>
> Both review-commit and merge vote are similar to voting
> on release candidates -- we vote on the bits of the candidate but neither vote
> on an idea nor a plan. (Of course, there are other types of vote for voting on
> a plan.)
>
> Regards,
> Tsz-Wo
>
>
>
>
>> On Thursday, October 24, 2013 3:46 PM, Doug Cutting
> <cu...@apache.org> wrote:
>> > On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth
> <cn...@hortonworks.com>
>> wrote:
>>
>>> When the voting happens on jira with a finalized merge patch, I know
>>> exactly what I'm voting for, because it's the same
>> review-and-commit
>>> process that we follow every day with the extra requirement of 3 +1s.
> When
>>> it happens on email, it's less clear to me exactly what I'm
> voting
>> for.
>>
>> Here's my take, FWIW. The entire project needs to determine whether
>> it is willing to take on the maintenance of code developed in a
>> branch. This vote needs the widest audience. On the other hand,
>> discussion on the umbrella Jira for the branch concerns the precise
>> details of the merge commit. Even if the project is generally willing
>> to accept maintenance of the code in a branch, committing it should
>> not break the build that day. So fine-tuning the precise details of
>> the merge often happens in Jira rather than as a part of the formal
>> merge vote. Sometimes these are determined in parallel.
>>
>> Since a -1 must always be accompanied by a rationale, it should be
>> clear whether such a vote concerns a fine point of the specific patch
>> that's easily corrected or whether it's about a fundamental problem
>> with the branch that will take longer to address. Either sort might
>> be cast in either place. A fine-point objection shouldn't reset
>> voting clocks and a fundamental objection concerns things that cannot
>> be fixed in a voting window. If something lies in the middle then
>> should be discussion until consensus is reached about whether the
>> merge date need be delayed, voting restarted later, etc. I don't see
>> a need for a more rigid policy here since we haven't seen things
>> running amok around branch merges due to a lack of policy.
>>
>> Is that consistent with other folks understanding?
>>
>> Doug
>>
>
Re: [DISCUSS] What is the purpose of merge vote threads?
Posted by Doug Cutting <cu...@apache.org>.
On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth <cn...@hortonworks.com> wrote:
> When the voting happens on jira with a finalized merge patch, I know
> exactly what I'm voting for, because it's the same review-and-commit
> process that we follow every day with the extra requirement of 3 +1s. When
> it happens on email, it's less clear to me exactly what I'm voting for.
Here's my take, FWIW. The entire project needs to determine whether
it is willing to take on the maintenance of code developed in a
branch. This vote needs the widest audience. On the other hand,
discussion on the umbrella Jira for the branch concerns the precise
details of the merge commit. Even if the project is generally willing
to accept maintenance of the code in a branch, committing it should
not break the build that day. So fine-tuning the precise details of
the merge often happens in Jira rather than as a part of the formal
merge vote. Sometimes these are determined in parallel.
Since a -1 must always be accompanied by a rationale, it should be
clear whether such a vote concerns a fine point of the specific patch
that's easily corrected or whether it's about a fundamental problem
with the branch that will take longer to address. Either sort might
be cast in either place. A fine-point objection shouldn't reset
voting clocks and a fundamental objection concerns things that cannot
be fixed in a voting window. If something lies in the middle then
should be discussion until consensus is reached about whether the
merge date need be delayed, voting restarted later, etc. I don't see
a need for a more rigid policy here since we haven't seen things
running amok around branch merges due to a lack of policy.
Is that consistent with other folks understanding?
Doug
Re: [DISCUSS] What is the purpose of merge vote threads?
Posted by Chris Nauroth <cn...@hortonworks.com>.
Hi Aaron,
Thanks for pointing this out. I hadn't seen it, but I just caught up.
This proposal states that 3 binding +1 votes are required for a branch
merge, which makes sense to me. My confusion arises from the fact that
I've seen the voting happening in 2 different places in 2 different ways
simultaneously: either directly on the jira with a finalized merge patch or
in an email thread. In the latter case, the process hasn't been
consistent. Sometimes the finalized merge patch is posted before the vote
begins, and sometimes the proposal comes with a dev plan describing
remaining work intended to be finished before the merge.
When the voting happens on jira with a finalized merge patch, I know
exactly what I'm voting for, because it's the same review-and-commit
process that we follow every day with the extra requirement of 3 +1s. When
it happens on email, it's less clear to me exactly what I'm voting for.
Whether the relevant voting happens on jira or email, this all comes down
to process questions around merges. To make this more specific, here are a
few questions:
Is a 7-day voting period required? This isn't stated in the bylaws or the
original proposal.
Does the vote begin when the devs present a finalized merge patch, or can
the vote begin earlier with intent to finish a few things before the vote
concludes?
If someone casts a binding -1, does that reset the clock on the vote?
If someone finds something that needs to be fixed, but doesn't cast a
binding -1, does that reset the clock on the vote?
Chris Nauroth
Hortonworks
http://hortonworks.com/
On Thu, Oct 24, 2013 at 2:07 PM, Aaron T. Myers <at...@apache.org> wrote:
> Hi Chris,
>
> Have you read the original thread on general@ which added this to the
> bylaws? At the beginning of that thread, Jakob provided some rationale for
> the branch merge vote and requiring three +1s.
>
> Link to that vote thread here:
>
> http://mail-archives.apache.org/mod_mbox/hadoop-general/201107.mbox/%3CCADiKvVvYhSTSBDokOqvapu-OYUrVEtOC+TCaqB2faQLisDWHbA@mail.gmail.com%3E
>
> The summary is roughly that because we might not adhere to the typical
> review process when committing to a branch (e.g. allowing non-committers
> binding +1s, or perhaps allowing CTR instead of RTC) that the act of
> merging in a development branch to trunk should require more scrutiny than
> just a single JIRA's worth of code change, and thus it's desirable to hold
> a separate merge vote which requires three +1s instead of the usual one.
>
> Best,
> Aaron
>
>
> On Fri, Oct 25, 2013 at 5:40 AM, Chris Nauroth <cnauroth@hortonworks.com
> >wrote:
>
> > I've realized that I'm very confused about the purpose and the process of
> > merge votes. I'd like to use this thread for clarification so that we
> all
> > know exactly what our votes on a merge thread mean. It's possible that
> > we'll even want to reconsider whether or not merge vote threads are
> useful.
> >
> > From what I can tell, there is no concrete action taken as a result of a
> > merge vote thread. If the vote passes, nothing happens. If the vote
> > doesn't pass, nothing happens. Instead, it is the +1 vote on the merge
> > patch in jira that really drives action. This differs from all other
> > voting topics, which do result in some concrete action if passed (new
> > release, change to the bylaws, etc.). Considering that, what value do we
> > get from merge vote threads?
> >
> > It seems the merge votes could be replaced entirely by the traditional
> code
> > review and commit process. Committers can respond directly on the
> umbrella
> > jira with +1 (or -1 and a list of what needs to be done to earn a +1).
> The
> > merge vote threads may in fact be detrimental, because they fork relevant
> > technical discussion away from the jira and into the mailing lists.
> Would
> > it be appropriate for us to say that the real merge vote happens on the
> > jira and do away with the process of conducting a separate vote on the
> > mailing list?
> >
> > Also, I don't see consistency in this process across sub-projects. Merge
> > vote threads have been more frequent in HDFS than YARN. If we continue
> to
> > use merge vote threads, then do we need to do this consistently across
> the
> > sub-projects?
> >
> > My first inclination was to review the bylaws for clarification. The
> > bylaws don't call out merges as a separate voting topic. Instead, merges
> > just fall under Code Change with the extra requirement of 3 +1s from
> > committers instead of 1. Again, this sounds like activity better suited
> to
> > the jira in question, where the proposed action is to commit a code
> change,
> > and committers and contributors enter comments to vote on acceptance of
> the
> > code and related artifacts like design docs and test plans.
> >
> > Of course, there may be a need to announce that a big feature is almost
> > ready and needs more reviewers. That could be handled by an email to the
> > dev lists, but I don't see the benefit of labeling that as a vote. Best
> > case scenario, the vote is redundant with the more meaningful activity
> > happening on the jira. Worst case scenario, the vote is a distraction
> and
> > introduces an artificial 7-day delay on code that has already received
> > votes in jira.
> >
> > Until I get some clarification on this, I don't think I can participate
> in
> > further merge vote threads in good conscience. I'll continue to offer my
> > +1 or -1 directly on feature jiras, where I know with certainty that I'm
> > voting on whether or not to accept something tangible.
> >
> > Thank you!
> >
> > Chris Nauroth
> > Hortonworks
> > http://hortonworks.com/
> >
> > --
> > CONFIDENTIALITY NOTICE
> > 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.
> >
>
--
CONFIDENTIALITY NOTICE
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.
Re: [DISCUSS] What is the purpose of merge vote threads?
Posted by "Aaron T. Myers" <at...@apache.org>.
Hi Chris,
Have you read the original thread on general@ which added this to the
bylaws? At the beginning of that thread, Jakob provided some rationale for
the branch merge vote and requiring three +1s.
Link to that vote thread here:
http://mail-archives.apache.org/mod_mbox/hadoop-general/201107.mbox/%3CCADiKvVvYhSTSBDokOqvapu-OYUrVEtOC+TCaqB2faQLisDWHbA@mail.gmail.com%3E
The summary is roughly that because we might not adhere to the typical
review process when committing to a branch (e.g. allowing non-committers
binding +1s, or perhaps allowing CTR instead of RTC) that the act of
merging in a development branch to trunk should require more scrutiny than
just a single JIRA's worth of code change, and thus it's desirable to hold
a separate merge vote which requires three +1s instead of the usual one.
Best,
Aaron
On Fri, Oct 25, 2013 at 5:40 AM, Chris Nauroth <cn...@hortonworks.com>wrote:
> I've realized that I'm very confused about the purpose and the process of
> merge votes. I'd like to use this thread for clarification so that we all
> know exactly what our votes on a merge thread mean. It's possible that
> we'll even want to reconsider whether or not merge vote threads are useful.
>
> From what I can tell, there is no concrete action taken as a result of a
> merge vote thread. If the vote passes, nothing happens. If the vote
> doesn't pass, nothing happens. Instead, it is the +1 vote on the merge
> patch in jira that really drives action. This differs from all other
> voting topics, which do result in some concrete action if passed (new
> release, change to the bylaws, etc.). Considering that, what value do we
> get from merge vote threads?
>
> It seems the merge votes could be replaced entirely by the traditional code
> review and commit process. Committers can respond directly on the umbrella
> jira with +1 (or -1 and a list of what needs to be done to earn a +1). The
> merge vote threads may in fact be detrimental, because they fork relevant
> technical discussion away from the jira and into the mailing lists. Would
> it be appropriate for us to say that the real merge vote happens on the
> jira and do away with the process of conducting a separate vote on the
> mailing list?
>
> Also, I don't see consistency in this process across sub-projects. Merge
> vote threads have been more frequent in HDFS than YARN. If we continue to
> use merge vote threads, then do we need to do this consistently across the
> sub-projects?
>
> My first inclination was to review the bylaws for clarification. The
> bylaws don't call out merges as a separate voting topic. Instead, merges
> just fall under Code Change with the extra requirement of 3 +1s from
> committers instead of 1. Again, this sounds like activity better suited to
> the jira in question, where the proposed action is to commit a code change,
> and committers and contributors enter comments to vote on acceptance of the
> code and related artifacts like design docs and test plans.
>
> Of course, there may be a need to announce that a big feature is almost
> ready and needs more reviewers. That could be handled by an email to the
> dev lists, but I don't see the benefit of labeling that as a vote. Best
> case scenario, the vote is redundant with the more meaningful activity
> happening on the jira. Worst case scenario, the vote is a distraction and
> introduces an artificial 7-day delay on code that has already received
> votes in jira.
>
> Until I get some clarification on this, I don't think I can participate in
> further merge vote threads in good conscience. I'll continue to offer my
> +1 or -1 directly on feature jiras, where I know with certainty that I'm
> voting on whether or not to accept something tangible.
>
> Thank you!
>
> Chris Nauroth
> Hortonworks
> http://hortonworks.com/
>
> --
> CONFIDENTIALITY NOTICE
> 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.
>