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
Re: Backporting policy proposal
On Mon, Jun 17, 2013 at 5:22 PM, Christopher <[EMAIL PROTECTED]> wrote:

> #5 was borne from Keith's frustration supporting the backport of the
> proxy. It may not apply to all features.

I definitely agree that we should have spent more time discussing the
implications of backporting 100,000 lines of generated code.  =)  I would
be OK with considering #5 on a case-by-case basis for major 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
> <[EMAIL PROTECTED]> wrote:
> > On Mon, Jun 17, 2013 at 10:07 AM, Christopher <[EMAIL PROTECTED]>
> 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