On Mon, Jun 17, 2013 at 10:07 AM, Christopher <ctubb...@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). > > 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). > > 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). > > 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. > > 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. > I'm not sure #5 makes sense. Certainly it's a sound idea not to do the back-porting until the feature design has been hammered out very well. However, in an example such as adding an iterator that we've agreed on back-porting, whose design is clear, it wouldn't make sense to wait until 1.6.0 comes out to actually add it to the 1.5 line. I could see an argument for placing additional testing requirements on back-ported features, like creating full-coverage unit tests and functional tests for the new code, to offset the risk of introducing code that has not yet gone through a full testing cycle and release process. I'm still deciding what I think about #4. For one, I'm reluctant to move the discussion of the feature from the ticket to the dev list. If we do decide to require a vote (either on ticket or dev list), we should also decide what type of approval is appropriate (consensus [1], majority [2], or a modified version of either, such as requiring fewer +1s but placing the same restrictions on -1s). Billie [1]: http://apache.org/foundation/glossary.html#ConsensusApproval [2]: http://apache.org/foundation/glossary.html#MajorityApproval > > Please discuss these points, or add your own. > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii >
