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

Switch to Plain View
Accumulo >> mail # dev >> Backporting policy proposal


+
Christopher 2013-06-17, 17:07
+
Billie Rinaldi 2013-06-17, 21:26
+
Dave Marion 2013-06-17, 22:35
+
Christopher 2013-06-18, 00:22
+
Billie Rinaldi 2013-06-18, 13:50
+
John Vines 2013-06-17, 20:02
+
Christopher 2013-06-17, 20:59
+
Christopher 2013-06-17, 21:05
+
Adam Fuchs 2013-06-18, 14:53
Copy link to this message
-
Re: Backporting policy proposal
On Tue, Jun 18, 2013 at 10:53 AM, Adam Fuchs <[EMAIL PROTECTED]> wrote:
> On Jun 17, 2013 1:07 PM, "Christopher" <[EMAIL PROTECTED]> wrote:
[snip agreement]
>> 2. Back-porting performance improvements to a prior release line that
>> is not EOL (end-of-life) is usually okay (subject to normal lazy
>> consensus), so long as it does not change user-facing behavior or API.
>> It is still strongly preferred to add such fixes in the older branch
>> first, and merge forward to the newer one(s).
>
> Agree, although doesn't the transition to git alleviate the problems with
> order of operations?

No, it complicates the goal of having newer versions share the entire
history of older versions in the workflow we've discussed for git.
(See Josh's comment about cherry-picking).

>> 3. Back-porting new features and additions are to be avoided as a
>> general rule (see arguments for this in previous threads:
>> ACCUMULO-1488 and http://s.apache.org/sU5 and probably others).
>
> This is an overly generalized and contentious statement that strips our
> committers of authority. There is no reason to state this given 4 and 5
> below. If we want to say something like this then we should narrow it to
> the non contentious classes of features, even loosly defined by
> thresholding the costs of maintenance, documentation, API effects, etc.

Yes, it is purposefully generalized (though I don't understand how it
is contentious... with what does it contend?), so that exceptions to
this rule can be objectively identified. It's a proposal, to be
considered in the context of #4 and #5. Establishing it as a general
guideline gives #4 and #5 meaning and scope.

It doesn't strip anybody of any authority. Committers will continue to
share authority with their other committer peers, as before. The only
change is how the authority is exercised (with active coordination
with other developers instead of passive). This just enforces engaging
with other developers on issues that have potential to disrupt the
efficiency of the development process.

>> 4. If it is desired to back-port a new feature, then a vote on the
>> developer mailing list should be called, due to the additional
>> development and support burden the new feature may cause for all
>> developers.
>
> Again, we should have a threshold here so that less than one hour of code
> change doesn't require three days of vote tracking. While additional
> attention should be payed to the cost of backporting features, it is
> important for us to trust and enable our developers to make good decisions.

What kind of threshold would you propose? And how do you objectively
(or even subjectively, with guidelines) measure the maintenance costs,
and the testing costs, the documentation costs, and the consistency
checks for compatibility during a release process? If we wanted to
rely solely on committer judgement, we could strip this item from the
proposal, and rely on #3 alone, as a general rule. However, then we're
going to have a lot of contention and split consensus whenever this
comes up, instead of simply follow a set of rules we've agreed to
follow in advance to avoid those issues.

>> 5. Even when it is agreed that a feature should be back-ported, it
>> should not be done unless/until a feature is first represented in a
>> newer release that has gone through the testing and release process,
>> and can be considered stable enough to back-port. This ensures focus
>> is kept on the main development branch for new features, and
>> significantly reduces the development burden of back-porting. It also
>> gives us a clear idea of the target behavior for the back-ported
>> feature, so that it will behave in the same way as the same feature in
>> the later release line.
>
> While the suggested rule would have the desire effect as listed, this is
> too broad a rule that eliminates much of the quick reation time that is
> really the whole point of backporting. If developers understand and agree
> on the costs of backporting, then do we really need a rule like this?

What happened with the proxy in 1.5, backported to 1.4 (Keith's
previously expressed frustration), seems to suggest that we do need
such a rule. But, this rule can be rolled into #4, in the sense that
it can be a consideration for each individual's vote. I do not see a
need to establish this as a strict "no exceptions" rule... just a
general guideline for consideration.

Christopher L Tubbs II
http://gravatar.com/ctubbsii
+
Keith Turner 2013-06-18, 16:05
+
Mike Drob 2013-06-18, 20:59
+
Christopher 2013-06-18, 17:55
+
Keith Turner 2013-06-18, 18:21
+
Josh Elser 2013-06-18, 15:05
+
Adam Fuchs 2013-06-18, 15:26
+
Josh Elser 2013-06-18, 15:43
+
John Vines 2013-06-18, 15:31
+
Josh Elser 2013-06-17, 23:35