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

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


Copy link to this message
-
Re: Backporting policy proposal
On Tue, Jun 18, 2013 at 1:55 PM, Christopher <[EMAIL PROTECTED]> wrote:

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

I am not sure every back port would be contentious, it really depends on
the specifics.  But even if every one were contentious, I think things
would still work out nicely in the long run.   I suspect if a few
contentious changes went through reversion votes, that memes related to
back porting would be influenced by this force of natural selection.
 Decisive revision votes would set precedent and influence future decisions
on back porting.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, Jun 18, 2013 at 12:05 PM, Keith Turner <[EMAIL PROTECTED]> wrote:
> > 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:
> >> >
> >> > 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