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
+1 for more structure. I like the idea of not back porting new features, it
will hopefully allow for more frequent releases of major/minor releases.

  Someone mentioned bylaws for the project; easily found a few examples (see
below). One even mentions the types of changes that will be in the different
types of releases.

[1] http://hc.apache.org/bylaws.html
[2] http://pig.apache.org/bylaws.html

-----Original Message-----
From: Billie Rinaldi [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 17, 2013 5:26 PM
Subject: Re: Backporting policy proposal

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 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).


[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