On Mon, Jun 17, 2013 at 5:22 PM, Christopher ctubb...@apache.org 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
On Jun 17, 2013 1:07 PM, 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
On 6/18/13 10:53 AM, Adam Fuchs wrote:
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
On Jun 18, 2013 11:05 AM, Josh Elser josh.el...@gmail.com wrote:
On 6/18/13 10:53 AM, Adam Fuchs wrote:
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
There are flow issues though, especially when you get into the realm of
rebasing, etc. So, like SVN, there should be one established direction.
On Tue, Jun 18, 2013 at 11:26 AM, Adam Fuchs afu...@apache.org wrote:
On Jun 18, 2013 11:05 AM, Josh Elser josh.el...@gmail.com wrote:
On 6/18/13
On 6/18/13 11:26 AM, Adam Fuchs wrote:
On Jun 18, 2013 11:05 AM, Josh Elser josh.el...@gmail.com wrote:
On 6/18/13 10:53 AM, Adam Fuchs wrote:
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),
On Tue, Jun 18, 2013 at 10:53 AM, Adam Fuchs afu...@apache.org wrote:
On Jun 17, 2013 1:07 PM, 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
On Tue, Jun 18, 2013 at 10:53 AM, Adam Fuchs afu...@apache.org wrote:
On Jun 17, 2013 1:07 PM, Christopher ctubb...@apache.org wrote:
[snip agreement]
2. Back-porting performance improvements to a prior release line that
is not EOL (end-of-life) is usually okay (subject to normal lazy
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*
On Tue, Jun 18, 2013 at 1:55 PM, Christopher ctubb...@apache.org wrote:
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
I think the point about CTR is very important, and should be weighed
carefully before making binding decisions regarding back-ports. If a
developer wants to spend time back-porting features, then I don't want to
be the one to dissuade them. Like I've heard on this list many times,
patches welcome!
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),
I think the issue here is that there is ambiguity on what a minor release
(minor minor?) is. Will 1.5.1 be only bugfixes, or are minor features
acceptable? If the former, what about bugs that are best resolved via
feature? If the latter, where is the line?
On Mon, Jun 17, 2013 at 1:07 PM,
Our versioning standard has been for quite some time now, the standard
Maven [major].[minor].[bugfix] versioning model. While we've perhaps
never really followed this strictly with regards to injecting minor
features into a bugfix version, it's a good model to follow, and my
proposal here would
I should also mention another argument against back-porting features.
With our discussions about documentation, the problem of back-porting
grows worse, because now we need to bombard users with more sets of
documentation that applies to each release. Whereas, if we were more
strict about bugfix
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:billie.rina...@gmail.com]
Sent: Monday, June 17, 2013 5:26 PM
To: dev@accumulo.apache.org
Subject: Re: Backporting policy proposal
On Mon
On 06/17/2013 01:07 PM, Christopher 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
17 matches
Mail list logo
