You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by dl...@comcast.net on 2013/05/22 03:52:48 UTC
Backporting features
Not sure if this has been decided already or not. Is there an official position on whether the 1.5 branch is feature frozen (and bug fixes only) when 1.5.0 is released? I'm finishing up ACCUMULO-1399 which I have been writing and testing against 1.6. I'd like to also backport to a 1.5.1. Thoughts?
-- Dave
Re: Backporting features
Posted by Josh Elser <jo...@gmail.com>.
IMO, if it can be backported without disrupting anything big from that
major release line, I'm ok with it. Given what it I understand of what
you have going in ACCUMULO-1399, I think that lines up.
With that said, I'd also encourage you to pull it back to 1.4 too, just
in case we have a reason to release a 1.4.4.
On 05/21/2013 09:52 PM, dlmarion@comcast.net wrote:
> Not sure if this has been decided already or not. Is there an official position on whether the 1.5 branch is feature frozen (and bug fixes only) when 1.5.0 is released? I'm finishing up ACCUMULO-1399 which I have been writing and testing against 1.6. I'd like to also backport to a 1.5.1. Thoughts?
>
> -- Dave
>
Re: Backporting features
Posted by Josh Elser <jo...@gmail.com>.
Ditto.
On 05/22/2013 03:16 PM, John Vines wrote:
> Personally, I would love to see new
> major releases done at least twice a year, not once.
Re: Backporting features
Posted by John Vines <vi...@apache.org>.
I like Keith's logic. One other point I would like to make is that
backporting features lengthens the amount of time between major releases
because it diminishes the returns. Personally, I would love to see new
major releases done at least twice a year, not once.
On Wed, May 22, 2013 at 2:59 PM, <dl...@comcast.net> wrote:
>
>
> I read all the feedback and its much appreciated. It sounds like we
> don't have a concensus, so I'm not sure how to proceed. It would be nice to
> say that the backporting features policy is either allowed, disallowed, or
> on a case-by-case basis. If not allowed and we have long release cycles
> then we likely run into the case where alternate distributions will pop up
> with the features backported. Is there a way to have a clean bug fix only
> version and an "unclean" version. For example , 1.5.1 and
> 1.5.1-with-features.
>
>
>
> ----- Original Message -----
>
>
> From: "Keith Turner" <ke...@deenlo.com>
> To: dev@accumulo.apache.org
> Sent: Wednesday, May 22, 2013 11:07:59 AM
> Subject: Re: Backporting features
>
> On Tue, May 21, 2013 at 9:52 PM, <dl...@comcast.net> wrote:
>
> >
> > Not sure if this has been decided already or not. Is there an official
> > position on whether the 1.5 branch is feature frozen (and bug fixes only)
> > when 1.5.0 is released? I'm finishing up ACCUMULO-1399 which I have been
> > writing and testing against 1.6. I'd like to also backport to a 1.5.1.
> > Thoughts?
> >
> > -- Dave
> >
>
>
> I am generally opposed to this for the following reasons.
>
> 1. Causes confusion for application that build on top of Accumulo.
> Consider the following.
>
> * Application W requires Accumulo 1.4.6 or later OR 1.5.2 or later.
> * Application X requires Accumulo 1.4.4 or later OR 1.5.1 or later.
> * Application Y requires Accumulo 1.4.5 or later OR 1.5.1 or later.
> * Application Z requires Accumulo 1.4.0 or later of 1.5.0 or later.
>
> Is the above desirable? This is what will happen if what used to be bug
> fix releases turn into new feature releases. It gets even more confusing
> when there are multiple levels of indirection.
>
> * Application A requires Gora 3.0 which requires Accumulo 1.4.6 or later
> or 1.5.1 or later. Application A also requires a laundry list of of other
> dependencies. You could easily see a situation where someone trying to
> install Application A spenda a lot of time trying to figure out why it does
> not work because they are running Accumulo 1.4.4.
>
> 2. Takes time away from developing new features. I have spent a lot of
> time keeping the proxy and MAC in sync in 1.4.
>
> 3. Has the potential to introduce new bugs.
>
> 4. I think its nice to take the time to kick the tires or new features.
> Which our current model gives us. Usually we have feature freeze, and then
> a month or two of beating on all of the new features in a release. If new
> features are immediately back ported, you lose this important time. For
> most of the features I have worked on, important refinements have happened
> during this time.
>
> 5. Similar to point 4 maybe even the same. By realeasing new features
> whenever, you loose opportunities to make multiple new features work
> together as a cohesive whole. For example if feature M and N are slated
> for 1.6.0, if M is implemented first and immediately released in 1.5.3, you
> loose the opportunity to easily make needed refinements to M as N is
> developed. As with Accumulo and Map Reduce, there are efficiencies to be
> gained from batching operations.
>
> I think instead of taking this approach, we should stick to feature and bug
> fix releases. We should get our feature relases out more frequently.
> 1.5.0 took way too long. We should try to do better w/ 1.6.0. I suspect
> part of the reason people want to add new features to bug fix releases is
> because 1.5.0 took so long.
>
> Keith
>
Re: Backporting features
Posted by Josh Elser <jo...@gmail.com>.
I will point out, the argument about additional effort to backport
changes in analogous to creating a new feature in an earlier version and
having to merge it more recent versions.
We typically don't have the latter because new features are never
(haven't previously?) added to a major release. Personally, I don't have
a problem if an application needs to depend on a new minor release for
some new capability, only if it would preclude some user from upgrading
to a new minor release.
Given how tied up some groups get about not switching to new major
releases of Accumulo, for new features that don't depend on the other
new features which necessitated a major release in the first place, it
seems we would pidgeon-hole people into having to upgrade to a new major
release for something completely separate.
The other solution here, I think Christopher mentioned it, would be to
keep it as a contrib/side-project and version it separately from "accumulo".
On 5/22/13 11:07 AM, Keith Turner wrote:
> On Tue, May 21, 2013 at 9:52 PM, <dl...@comcast.net> wrote:
>
>>
>> Not sure if this has been decided already or not. Is there an official
>> position on whether the 1.5 branch is feature frozen (and bug fixes only)
>> when 1.5.0 is released? I'm finishing up ACCUMULO-1399 which I have been
>> writing and testing against 1.6. I'd like to also backport to a 1.5.1.
>> Thoughts?
>>
>> -- Dave
>>
>
>
> I am generally opposed to this for the following reasons.
>
> 1. Causes confusion for application that build on top of Accumulo.
> Consider the following.
>
> * Application W requires Accumulo 1.4.6 or later OR 1.5.2 or later.
> * Application X requires Accumulo 1.4.4 or later OR 1.5.1 or later.
> * Application Y requires Accumulo 1.4.5 or later OR 1.5.1 or later.
> * Application Z requires Accumulo 1.4.0 or later of 1.5.0 or later.
>
> Is the above desirable? This is what will happen if what used to be bug
> fix releases turn into new feature releases. It gets even more confusing
> when there are multiple levels of indirection.
>
> * Application A requires Gora 3.0 which requires Accumulo 1.4.6 or later
> or 1.5.1 or later. Application A also requires a laundry list of of other
> dependencies. You could easily see a situation where someone trying to
> install Application A spenda a lot of time trying to figure out why it does
> not work because they are running Accumulo 1.4.4.
>
> 2. Takes time away from developing new features. I have spent a lot of
> time keeping the proxy and MAC in sync in 1.4.
>
> 3. Has the potential to introduce new bugs.
>
> 4. I think its nice to take the time to kick the tires or new features.
> Which our current model gives us. Usually we have feature freeze, and then
> a month or two of beating on all of the new features in a release. If new
> features are immediately back ported, you lose this important time. For
> most of the features I have worked on, important refinements have happened
> during this time.
>
> 5. Similar to point 4 maybe even the same. By realeasing new features
> whenever, you loose opportunities to make multiple new features work
> together as a cohesive whole. For example if feature M and N are slated
> for 1.6.0, if M is implemented first and immediately released in 1.5.3, you
> loose the opportunity to easily make needed refinements to M as N is
> developed. As with Accumulo and Map Reduce, there are efficiencies to be
> gained from batching operations.
>
> I think instead of taking this approach, we should stick to feature and bug
> fix releases. We should get our feature relases out more frequently.
> 1.5.0 took way too long. We should try to do better w/ 1.6.0. I suspect
> part of the reason people want to add new features to bug fix releases is
> because 1.5.0 took so long.
>
> Keith
>
Re: Backporting features
Posted by dl...@comcast.net.
I read all the feedback and its much appreciated. It sounds like we don't have a concensus, so I'm not sure how to proceed. It would be nice to say that the backporting features policy is either allowed, disallowed, or on a case-by-case basis. If not allowed and we have long release cycles then we likely run into the case where alternate distributions will pop up with the features backported. Is there a way to have a clean bug fix only version and an "unclean" version. For example , 1.5.1 and 1.5.1-with-features.
----- Original Message -----
From: "Keith Turner" <ke...@deenlo.com>
To: dev@accumulo.apache.org
Sent: Wednesday, May 22, 2013 11:07:59 AM
Subject: Re: Backporting features
On Tue, May 21, 2013 at 9:52 PM, <dl...@comcast.net> wrote:
>
> Not sure if this has been decided already or not. Is there an official
> position on whether the 1.5 branch is feature frozen (and bug fixes only)
> when 1.5.0 is released? I'm finishing up ACCUMULO-1399 which I have been
> writing and testing against 1.6. I'd like to also backport to a 1.5.1.
> Thoughts?
>
> -- Dave
>
I am generally opposed to this for the following reasons.
1. Causes confusion for application that build on top of Accumulo.
Consider the following.
* Application W requires Accumulo 1.4.6 or later OR 1.5.2 or later.
* Application X requires Accumulo 1.4.4 or later OR 1.5.1 or later.
* Application Y requires Accumulo 1.4.5 or later OR 1.5.1 or later.
* Application Z requires Accumulo 1.4.0 or later of 1.5.0 or later.
Is the above desirable? This is what will happen if what used to be bug
fix releases turn into new feature releases. It gets even more confusing
when there are multiple levels of indirection.
* Application A requires Gora 3.0 which requires Accumulo 1.4.6 or later
or 1.5.1 or later. Application A also requires a laundry list of of other
dependencies. You could easily see a situation where someone trying to
install Application A spenda a lot of time trying to figure out why it does
not work because they are running Accumulo 1.4.4.
2. Takes time away from developing new features. I have spent a lot of
time keeping the proxy and MAC in sync in 1.4.
3. Has the potential to introduce new bugs.
4. I think its nice to take the time to kick the tires or new features.
Which our current model gives us. Usually we have feature freeze, and then
a month or two of beating on all of the new features in a release. If new
features are immediately back ported, you lose this important time. For
most of the features I have worked on, important refinements have happened
during this time.
5. Similar to point 4 maybe even the same. By realeasing new features
whenever, you loose opportunities to make multiple new features work
together as a cohesive whole. For example if feature M and N are slated
for 1.6.0, if M is implemented first and immediately released in 1.5.3, you
loose the opportunity to easily make needed refinements to M as N is
developed. As with Accumulo and Map Reduce, there are efficiencies to be
gained from batching operations.
I think instead of taking this approach, we should stick to feature and bug
fix releases. We should get our feature relases out more frequently.
1.5.0 took way too long. We should try to do better w/ 1.6.0. I suspect
part of the reason people want to add new features to bug fix releases is
because 1.5.0 took so long.
Keith
Re: Backporting features
Posted by Keith Turner <ke...@deenlo.com>.
On Tue, May 21, 2013 at 9:52 PM, <dl...@comcast.net> wrote:
>
> Not sure if this has been decided already or not. Is there an official
> position on whether the 1.5 branch is feature frozen (and bug fixes only)
> when 1.5.0 is released? I'm finishing up ACCUMULO-1399 which I have been
> writing and testing against 1.6. I'd like to also backport to a 1.5.1.
> Thoughts?
>
> -- Dave
>
I am generally opposed to this for the following reasons.
1. Causes confusion for application that build on top of Accumulo.
Consider the following.
* Application W requires Accumulo 1.4.6 or later OR 1.5.2 or later.
* Application X requires Accumulo 1.4.4 or later OR 1.5.1 or later.
* Application Y requires Accumulo 1.4.5 or later OR 1.5.1 or later.
* Application Z requires Accumulo 1.4.0 or later of 1.5.0 or later.
Is the above desirable? This is what will happen if what used to be bug
fix releases turn into new feature releases. It gets even more confusing
when there are multiple levels of indirection.
* Application A requires Gora 3.0 which requires Accumulo 1.4.6 or later
or 1.5.1 or later. Application A also requires a laundry list of of other
dependencies. You could easily see a situation where someone trying to
install Application A spenda a lot of time trying to figure out why it does
not work because they are running Accumulo 1.4.4.
2. Takes time away from developing new features. I have spent a lot of
time keeping the proxy and MAC in sync in 1.4.
3. Has the potential to introduce new bugs.
4. I think its nice to take the time to kick the tires or new features.
Which our current model gives us. Usually we have feature freeze, and then
a month or two of beating on all of the new features in a release. If new
features are immediately back ported, you lose this important time. For
most of the features I have worked on, important refinements have happened
during this time.
5. Similar to point 4 maybe even the same. By realeasing new features
whenever, you loose opportunities to make multiple new features work
together as a cohesive whole. For example if feature M and N are slated
for 1.6.0, if M is implemented first and immediately released in 1.5.3, you
loose the opportunity to easily make needed refinements to M as N is
developed. As with Accumulo and Map Reduce, there are efficiencies to be
gained from batching operations.
I think instead of taking this approach, we should stick to feature and bug
fix releases. We should get our feature relases out more frequently.
1.5.0 took way too long. We should try to do better w/ 1.6.0. I suspect
part of the reason people want to add new features to bug fix releases is
because 1.5.0 took so long.
Keith
Re: Backporting features
Posted by Christopher <ct...@apache.org>.
I don't know about precedent, but...
My general opinion is that new features shouldn't be back-ported to
the main branch of older release lines, unless there's a compelling
reason. Instead, they should be supported as separate add-on that one
can compile in (perhaps as a patch in the contrib area?), or as a
forked branch.
The reason for this opinion is that it can be surprising and
disruptive for users if they end up relying on new features in a
bugfix'd version, and for whatever reason, have to switch to an
earlier version of the same release line (perhaps a bug was found in a
bug-fix, and they were forced to roll back, or they move to a system
that hasn't yet been upgraded).
A second reason for this is that back-ported features can often behave
in ways that are different from the way they behave in the branch in
which they were introduced, and this can also introduce confusion.
Of course, this is just a general opinion... any specific opinion
about a particular feature, I'd have to form on a case-by-case basis.
I think MiniAccumuloCluster, for instance, was a great thing to
backport, because of it's ability to enable testing of the core
functionality, rather than it actually modifying any core
functionality. I'm less enthusiastic about backporting the proxy, but
I can see how it could be useful, especially if it helped people
transition seamlessly to newer versions of Accumulo without re-writing
lots of utility code.
I should also mention that one of the reasons I was thinking about
git, and initiated a discussion about that today on this list, was
because I was thinking about the convenience it might provide enabling
the creation of forked branches with backported features (rather than
include them in the "official" release line)... though that particular
application of git might need further discussion (because it can be
annoying to have an excessive number of branches for backported
features).
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, May 21, 2013 at 10:04 PM, <dl...@comcast.net> wrote:
> I was using my issue as an example and was looking for a general policy from the community. Sounds like it has already been talked about and there is a precedent.
>
> ----- Original Message -----
> From: "Corey Nolet" <cj...@gmail.com>
> To: dev@accumulo.apache.org
> Sent: Tuesday, May 21, 2013 10:02:14 PM
> Subject: Re: Backporting features
>
> Maybe this is opening a can of worms- but if the proxy was backported to
> 1.4.4, I can't see why your new work shouldn't be.
Re: Backporting features
Posted by dl...@comcast.net.
I was using my issue as an example and was looking for a general policy from the community. Sounds like it has already been talked about and there is a precedent.
----- Original Message -----
From: "Corey Nolet" <cj...@gmail.com>
To: dev@accumulo.apache.org
Sent: Tuesday, May 21, 2013 10:02:14 PM
Subject: Re: Backporting features
Maybe this is opening a can of worms- but if the proxy was backported to
1.4.4, I can't see why your new work shouldn't be.
Re: Backporting features
Posted by Corey Nolet <cj...@gmail.com>.
Maybe this is opening a can of worms- but if the proxy was backported to
1.4.4, I can't see why your new work shouldn't be.