Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo >> mail # dev >> Backporting policy proposal


+
Christopher 2013-06-17, 17:07
+
Billie Rinaldi 2013-06-17, 21:26
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
To: [EMAIL PROTECTED]
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).

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
>
+
Christopher 2013-06-18, 00:22
+
Billie Rinaldi 2013-06-18, 13:50
+
John Vines 2013-06-17, 20:02
+
Christopher 2013-06-17, 20:59
+
Christopher 2013-06-17, 21:05
+
Adam Fuchs 2013-06-18, 14:53
+
Christopher 2013-06-18, 17:50
+
Keith Turner 2013-06-18, 16:05
+
Mike Drob 2013-06-18, 20:59
+
Christopher 2013-06-18, 17:55
+
Keith Turner 2013-06-18, 18:21
+
Josh Elser 2013-06-18, 15:05
+
Adam Fuchs 2013-06-18, 15:26
+
Josh Elser 2013-06-18, 15:43
+
John Vines 2013-06-18, 15:31
+
Josh Elser 2013-06-17, 23:35
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB