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
Copy link to this message
Re: Backporting policy proposal
On Jun 17, 2013 1:07 PM, "Christopher" <[EMAIL PROTECTED]> wrote:
> I propose we adopt a more structured policy beyond simple "lazy
> consensus" to be apply to backporting features. Some guidelines I'd
> like to see in this policy, include:
> 1. Back-porting bugfixes to a prior release line that is not EOL
> (end-of-life) is always okay (subject to normal lazy consensus), but
> it is strongly preferred to fix it first in the older branch and merge
> forward to the newer one(s).


> 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?

> 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.

> 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.

> 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?

Christopher 2013-06-18, 17:50
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