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. Please discuss these points, or add your own. -- Christopher L Tubbs II http://gravatar.com/ctubbsii
