Home | About | Sematext search-lucene.com search-hadoop.com
 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
+
Dave Marion 2013-06-17, 22:35
+
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
Copy link to this message
-
Re: Backporting policy proposal
Christopher 2013-06-18, 17:55
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 <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 18, 2013 at 10:53 AM, Adam Fuchs <[EMAIL PROTECTED]> wrote:
>
>> On Jun 17, 2013 1:07 PM, "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).
>>
>> 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
+
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