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
-
Backporting policy proposal
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