#5 was borne from Keith's frustration supporting the backport of the proxy. It may not apply to all features.
I think the dev list is the appropriate place for decisions about inclusion of issues into particular branches, where the ticket is more appropriate to discuss the feature itself. The dev list seems to be the place where we consciously include the whole developer community, rather than just those interested in a particular feature (back-porting features seems to have the potential to impact all developers, plus it seems to me less likely to divide the community on particular features). Also, I personally track the threads in the dev list more closely than all the comments on all the tickets (so I assume others do, too). However, I don't feel strongly about this point, so long as there is an explicit community decision to port a feature to a previous version, and take on the additional costs of doing so, under the recognition that this diverts time and effort away from the next feature release version. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, Jun 17, 2013 at 5:26 PM, Billie Rinaldi <billie.rina...@gmail.com> wrote: > 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 >>
