accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: Backporting policy proposal
Date Tue, 18 Jun 2013 17:55:45 GMT
Dealing with contentious changes might be a good addition to an
established set of by-laws, and would certainly help alleviate some
potential issues. However, I think we also need to establish
guidelines for back-porting specifically, because these have the
potential to be contentious *every* time.

Christopher L Tubbs II

On Tue, Jun 18, 2013 at 12:05 PM, Keith Turner <> wrote:
> On Tue, Jun 18, 2013 at 10:53 AM, Adam Fuchs <> wrote:
>> On Jun 17, 2013 1:07 PM, "Christopher" <> 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).
>> Agree.
>> >
>> > 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 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.
> Another avenue is to define a clear process dealing with contentious
> changes. Consider the case where a developer backports a feature and other
> developers think its deficient in some way.  If the developer who back
> ported will not fix the issues, then other developers are faced with the
> prospect of fixing the issues, ignoring them and letting users deal with
> it, or reverting the change.  If no one steps up to fix it and some devs
> are opposed to reverting it, I think we should be able to call a vote on
> reverting the change.   This process would be more inline with our current
> CTR workflow.  I think this approach would result in less overhead.
>> >
>> > 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?
>> Adam

View raw message