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
Josh Elser 2013-06-17, 23:35
On 06/17/2013 01: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).
Agreed
> 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).
Agreed
> 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).
Agree with caveat incoming on #4
> 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.
Mainly agree, although my opinion is more driven by wanting to not stall
out major releases. New major features, as scary as they may be, should
be addressed head-on with ourselves giving them adequate testing. Over
time, this should alleviate the desire to backport things so frequently.
> 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.
Mostly agree. I think there should be a higher-bar to reach when
including something significant in a previously released version in
regards to testing, stability and API-compatibilty. I would hope our
devs would do this on their own, but perhaps it's good to be explicit.
Again, I do like the focus on including new things in the
active-development version.
> Please discuss these points, or add your own.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii