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
