Dealing with contentious changes might be a good addition to an established set of by-laws, and would certainly help alleviate some potential issues. However, I think we also need to establish guidelines for back-porting specifically, because these have the potential to be contentious *every* time.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Jun 18, 2013 at 12:05 PM, Keith Turner <ke...@deenlo.com> wrote: > On Tue, Jun 18, 2013 at 10:53 AM, Adam Fuchs <afu...@apache.org> wrote: > >> 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. >> > > Another avenue is to define a clear process dealing with contentious > changes. Consider the case where a developer backports a feature and other > developers think its deficient in some way. If the developer who back > ported will not fix the issues, then other developers are faced with the > prospect of fixing the issues, ignoring them and letting users deal with > it, or reverting the change. If no one steps up to fix it and some devs > are opposed to reverting it, I think we should be able to call a vote on > reverting the change. This process would be more inline with our current > CTR workflow. I think this approach would result in less overhead. > > >> > >> > 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 >>
