Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: error (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAPMpPc6fs0kvC=TBG8uktWDqCgJBSvnEy88CCnbmORoo2yjv_Q@mail.gmail.com>
References: 
 <CAL5zq9YoJA=caJzXC_vmY-di=ijhJ_W0rhQJzEWHkxfrB2imGg@mail.gmail.com>
	<CAPMpPc6fs0kvC=TBG8uktWDqCgJBSvnEy88CCnbmORoo2yjv_Q@mail.gmail.com>
Date: Tue, 18 Jun 2013 12:05:04 -0400
Message-ID: 
 <CAGUtCHrNs251b4QDp8+Lr6gNtZ+nC6U4JB2n-ZOQWgxsdgR-Ow@mail.gmail.com>
Subject: Re: Backporting policy proposal
From: Keith Turner <keith@deenlo.com>
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=089e0149d35850b86604df6fe08b

--089e0149d35850b86604df6fe08b
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jun 18, 2013 at 10:53 AM, Adam Fuchs <afuchs@apache.org> wrote:

> On Jun 17, 2013 1:07 PM, "Christopher" <ctubbsii@apache.org> 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 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.
>

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
>

--089e0149d35850b86604df6fe08b--