On Jun 17, 2013 1:07 PM, "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).
Agree. > > 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). Agree, although doesn't the transition to git alleviate the problems with order of operations? > > 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). This is an overly generalized and contentious statement that strips our committers of authority. There is no reason to state this given 4 and 5 below. If we want to say something like this then we should narrow it to the non contentious classes of features, even loosly defined by thresholding the costs of maintenance, documentation, API effects, etc. > > 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. Again, we should have a threshold here so that less than one hour of code change doesn't require three days of vote tracking. While additional attention should be payed to the cost of backporting features, it is important for us to trust and enable our developers to make good decisions. > > 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. While the suggested rule would have the desire effect as listed, this is too broad a rule that eliminates much of the quick reation time that is really the whole point of backporting. If developers understand and agree on the costs of backporting, then do we really need a rule like this? Adam
