[DISCUSS] Question about 1.7 bugfix releases

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Question about 1.7 bugfix releases

Christopher Tubbs-2
Now that we do semver, and 1.8 has been broken in a bit, do we need to
continue to support 1.7 releases with bugfixes? There is a fully
backwards-compatible upgrade path from 1.7 to 1.8. So, it seems we probably
don't need to support new 1.7.x to 1.7.(x+1) upgrade paths any more.

Not sure. Thoughts?
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Josh Elser-2
Upgrade compatibility doesn't necessary mean that real organizations can
perform the upgrade (I've seen my fair-share of reasons that
organization cannot/will-not upgrade for some period of time). This
typically has a minimum time-line of a couple of months to make and
schedule the work.

I assume we have no idea about who is using what version -- sending a
note to users@ would might generate some helpful feedback. We could also
look at known downstream integrations to see if they have done 1.8
testing (e.g. Pig, Hive, Presto), if nothing else, to let them all know
"change is a'coming".

As a developer, I'd like to retire 1.7, but I'm not sure if it's
realistic yet. Regardless, this conversation is certainly a good idea.


On 6/1/17 6:33 PM, Christopher wrote:
> Now that we do semver, and 1.8 has been broken in a bit, do we need to
> continue to support 1.7 releases with bugfixes? There is a fully
> backwards-compatible upgrade path from 1.7 to 1.8. So, it seems we probably
> don't need to support new 1.7.x to 1.7.(x+1) upgrade paths any more.
>
> Not sure. Thoughts?
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Christopher Tubbs-2
On Fri, Jun 2, 2017 at 2:15 PM Josh Elser <[hidden email]> wrote:

> Upgrade compatibility doesn't necessary mean that real organizations can
> perform the upgrade (I've seen my fair-share of reasons that
> organization cannot/will-not upgrade for some period of time). This
> typically has a minimum time-line of a couple of months to make and
> schedule the work.
>
>
True, and I can think of some reasons that would make my own life difficult
(dependency convergence in Fedora RPM packages might make it hard to update
to a new backwards-compatible version which has new dependencies).

However, I'm also coming at this from some perspectives I've gotten from
users at $dayjob. When we released 1.7.3 and 1.8.1, several people emailed
me with some confusion, asking which one they should upgrade to. In
general, when people are considering such upgrades, I would simply
recommend the later one, so that's what I did... but then they asked me,
"Who exactly is 1.7.3 for, then?" and I couldn't really think of an answer
I thought was a good one. For most people... either you can upgrade or you
can't. If you can upgrade, upgrade to the latest one which is compatible.
If you can't upgrade, then why care about 1.7.3?

I realize there's some cases, where upgrading to 1.7.3 is easy, but 1.8.1
is harder... my own example above. But, from my understanding of how most
users package and deploy Accumulo with bundled dependencies, I can't
imagine many scenarios where there's a reason to upgrade only to 1.7.3
instead of going to 1.8.1, except that we, as developers have provided that
option... some there may be some perceptions that the larger jump is
riskier in some way (when that's not necessarily the case, especially once
the new line has had a chance to have been shown to be stable).

The user confusion is exacerbated by the fact that sometimes the release
timing results in the earlier release line having bug fixes which have not
yet made it in to the newer release line. And, our motivation to do a new
release in the newer line is lowered from having recently done two prior
releases. If we weren't doing new bugfixes in the previous line after the
latest has stabilized, there'd probably be more motivation to do more
bugfix releases in the latest line.


> I assume we have no idea about who is using what version -- sending a
> note to users@ would might generate some helpful feedback. We could also
> look at known downstream integrations to see if they have done 1.8
> testing (e.g. Pig, Hive, Presto), if nothing else, to let them all know
> "change is a'coming".
>
>
Is there any chance you'd be willing to pose some questions to the user
list to solicit some feedback? I fear that I won't be able to frame the
questions well enough to get the kind of feedback we need to decide on
something like this.



> As a developer, I'd like to retire 1.7, but I'm not sure if it's
> realistic yet. Regardless, this conversation is certainly a good idea.
>
>
> On 6/1/17 6:33 PM, Christopher wrote:
> > Now that we do semver, and 1.8 has been broken in a bit, do we need to
> > continue to support 1.7 releases with bugfixes? There is a fully
> > backwards-compatible upgrade path from 1.7 to 1.8. So, it seems we
> probably
> > don't need to support new 1.7.x to 1.7.(x+1) upgrade paths any more.
> >
> > Not sure. Thoughts?
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Sean Busbey
Many users in enterprise spaces have rules for upgrading to
a new maintenance release that are different from upgrading to a new
minor release. Those rules presume a uniform understanding of the
risks involved in each of those kinds of releases that I don't think
exists, especially across open source projects, but nonetheless those
are the rules the organization is stuck with. For those users,
continued maintenance releases that include critical bug fixes are key
to allowing them to consume our releases.

It's true the release timing can make things awkward by getting some
critical fix out for an earlier release line first, but that just
points to a need for more releases.



On Fri, Jun 2, 2017 at 10:18 PM, Christopher <[hidden email]> wrote:

> On Fri, Jun 2, 2017 at 2:15 PM Josh Elser <[hidden email]> wrote:
>
>> Upgrade compatibility doesn't necessary mean that real organizations can
>> perform the upgrade (I've seen my fair-share of reasons that
>> organization cannot/will-not upgrade for some period of time). This
>> typically has a minimum time-line of a couple of months to make and
>> schedule the work.
>>
>>
> True, and I can think of some reasons that would make my own life difficult
> (dependency convergence in Fedora RPM packages might make it hard to update
> to a new backwards-compatible version which has new dependencies).
>
> However, I'm also coming at this from some perspectives I've gotten from
> users at $dayjob. When we released 1.7.3 and 1.8.1, several people emailed
> me with some confusion, asking which one they should upgrade to. In
> general, when people are considering such upgrades, I would simply
> recommend the later one, so that's what I did... but then they asked me,
> "Who exactly is 1.7.3 for, then?" and I couldn't really think of an answer
> I thought was a good one. For most people... either you can upgrade or you
> can't. If you can upgrade, upgrade to the latest one which is compatible.
> If you can't upgrade, then why care about 1.7.3?
>
> I realize there's some cases, where upgrading to 1.7.3 is easy, but 1.8.1
> is harder... my own example above. But, from my understanding of how most
> users package and deploy Accumulo with bundled dependencies, I can't
> imagine many scenarios where there's a reason to upgrade only to 1.7.3
> instead of going to 1.8.1, except that we, as developers have provided that
> option... some there may be some perceptions that the larger jump is
> riskier in some way (when that's not necessarily the case, especially once
> the new line has had a chance to have been shown to be stable).
>
> The user confusion is exacerbated by the fact that sometimes the release
> timing results in the earlier release line having bug fixes which have not
> yet made it in to the newer release line. And, our motivation to do a new
> release in the newer line is lowered from having recently done two prior
> releases. If we weren't doing new bugfixes in the previous line after the
> latest has stabilized, there'd probably be more motivation to do more
> bugfix releases in the latest line.
>
>
>> I assume we have no idea about who is using what version -- sending a
>> note to users@ would might generate some helpful feedback. We could also
>> look at known downstream integrations to see if they have done 1.8
>> testing (e.g. Pig, Hive, Presto), if nothing else, to let them all know
>> "change is a'coming".
>>
>>
> Is there any chance you'd be willing to pose some questions to the user
> list to solicit some feedback? I fear that I won't be able to frame the
> questions well enough to get the kind of feedback we need to decide on
> something like this.
>
>
>
>> As a developer, I'd like to retire 1.7, but I'm not sure if it's
>> realistic yet. Regardless, this conversation is certainly a good idea.
>>
>>
>> On 6/1/17 6:33 PM, Christopher wrote:
>> > Now that we do semver, and 1.8 has been broken in a bit, do we need to
>> > continue to support 1.7 releases with bugfixes? There is a fully
>> > backwards-compatible upgrade path from 1.7 to 1.8. So, it seems we
>> probably
>> > don't need to support new 1.7.x to 1.7.(x+1) upgrade paths any more.
>> >
>> > Not sure. Thoughts?
>> >
>>



--
busbey
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Josh Elser-2
Thanks, Sean. You've rewarded my laziness in replying to Christopher :)

The only thing I have to expand on is: even though, as developers, we
know that the 1.7.3 to 1.8.1 upgrade is no harder than to a 1.7.x,
"reasons" (often, nonsensical or outright bad reasons) can block people
from doing it. Policy often dictates the limitations infrastructures
group must work with. Often, threat/worry of risk greatly exceeds actual
risk for groups working in these environments.

On 6/5/17 10:58 AM, Sean Busbey wrote:

> Many users in enterprise spaces have rules for upgrading to
> a new maintenance release that are different from upgrading to a new
> minor release. Those rules presume a uniform understanding of the
> risks involved in each of those kinds of releases that I don't think
> exists, especially across open source projects, but nonetheless those
> are the rules the organization is stuck with. For those users,
> continued maintenance releases that include critical bug fixes are key
> to allowing them to consume our releases.
>
> It's true the release timing can make things awkward by getting some
> critical fix out for an earlier release line first, but that just
> points to a need for more releases.
>
>
>
> On Fri, Jun 2, 2017 at 10:18 PM, Christopher <[hidden email]> wrote:
>> On Fri, Jun 2, 2017 at 2:15 PM Josh Elser <[hidden email]> wrote:
>>
>>> Upgrade compatibility doesn't necessary mean that real organizations can
>>> perform the upgrade (I've seen my fair-share of reasons that
>>> organization cannot/will-not upgrade for some period of time). This
>>> typically has a minimum time-line of a couple of months to make and
>>> schedule the work.
>>>
>>>
>> True, and I can think of some reasons that would make my own life difficult
>> (dependency convergence in Fedora RPM packages might make it hard to update
>> to a new backwards-compatible version which has new dependencies).
>>
>> However, I'm also coming at this from some perspectives I've gotten from
>> users at $dayjob. When we released 1.7.3 and 1.8.1, several people emailed
>> me with some confusion, asking which one they should upgrade to. In
>> general, when people are considering such upgrades, I would simply
>> recommend the later one, so that's what I did... but then they asked me,
>> "Who exactly is 1.7.3 for, then?" and I couldn't really think of an answer
>> I thought was a good one. For most people... either you can upgrade or you
>> can't. If you can upgrade, upgrade to the latest one which is compatible.
>> If you can't upgrade, then why care about 1.7.3?
>>
>> I realize there's some cases, where upgrading to 1.7.3 is easy, but 1.8.1
>> is harder... my own example above. But, from my understanding of how most
>> users package and deploy Accumulo with bundled dependencies, I can't
>> imagine many scenarios where there's a reason to upgrade only to 1.7.3
>> instead of going to 1.8.1, except that we, as developers have provided that
>> option... some there may be some perceptions that the larger jump is
>> riskier in some way (when that's not necessarily the case, especially once
>> the new line has had a chance to have been shown to be stable).
>>
>> The user confusion is exacerbated by the fact that sometimes the release
>> timing results in the earlier release line having bug fixes which have not
>> yet made it in to the newer release line. And, our motivation to do a new
>> release in the newer line is lowered from having recently done two prior
>> releases. If we weren't doing new bugfixes in the previous line after the
>> latest has stabilized, there'd probably be more motivation to do more
>> bugfix releases in the latest line.
>>
>>
>>> I assume we have no idea about who is using what version -- sending a
>>> note to users@ would might generate some helpful feedback. We could also
>>> look at known downstream integrations to see if they have done 1.8
>>> testing (e.g. Pig, Hive, Presto), if nothing else, to let them all know
>>> "change is a'coming".
>>>
>>>
>> Is there any chance you'd be willing to pose some questions to the user
>> list to solicit some feedback? I fear that I won't be able to frame the
>> questions well enough to get the kind of feedback we need to decide on
>> something like this.
>>
>>
>>
>>> As a developer, I'd like to retire 1.7, but I'm not sure if it's
>>> realistic yet. Regardless, this conversation is certainly a good idea.
>>>
>>>
>>> On 6/1/17 6:33 PM, Christopher wrote:
>>>> Now that we do semver, and 1.8 has been broken in a bit, do we need to
>>>> continue to support 1.7 releases with bugfixes? There is a fully
>>>> backwards-compatible upgrade path from 1.7 to 1.8. So, it seems we
>>> probably
>>>> don't need to support new 1.7.x to 1.7.(x+1) upgrade paths any more.
>>>>
>>>> Not sure. Thoughts?
>>>>
>>>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Christopher Tubbs-2
In reply to this post by Sean Busbey
On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <[hidden email]> wrote:

> Many users in enterprise spaces have rules for upgrading to
> a new maintenance release that are different from upgrading to a new
> minor release. Those rules presume a uniform understanding of the
> risks involved in each of those kinds of releases that I don't think
> exists, especially across open source projects, but nonetheless those
> are the rules the organization is stuck with. For those users,
> continued maintenance releases that include critical bug fixes are key
> to allowing them to consume our releases.
>
>
I agree that occurs, but I also think that such rules in enterprises don't
exist in a vacuum. They exist in the context of what the project itself is
doing. Choosing to upgrade to a new maintenance release is only an option
when the upstream project is still producing maintenance releases. Since
that's at the core of what this discussion is about, the question becomes
something like "If we do this, will we be encouraging [enterprise and
other] users to use the latest minor.patch release on their next upgrade
cycle, or are we discouraging them from upgrading at all?" I don't know the
answer, but if it's the latter, the next question is "Can we correct for
any misperceived risks by better communicating what we know about upgrade
risks to newer minor versions?" I don't know the answer to that question,
either.

In my experience with my "enterprise" customers, the reluctance to upgrade
seems to apply equally to all versions. I recently provided support to
somebody still running 1.5.0, in spite of the 1.5 line being on 1.5.4 and
*very* EOL, because of reluctance to upgrade.



> It's true the release timing can make things awkward by getting some
> critical fix out for an earlier release line first, but that just
> points to a need for more releases.
>
>

Agreed. We need more releases. What I'm thinking is that more releases
would be easier for us to do if we drop maintenance branches for minor
versions which have a clear upgrade path to a stable newer minor release.
I'm also wondering if we can reduce confusion on users, and encourage
upgrading, by reducing the number of possible upgrade paths.


>
>
> On Fri, Jun 2, 2017 at 10:18 PM, Christopher <[hidden email]> wrote:
> > On Fri, Jun 2, 2017 at 2:15 PM Josh Elser <[hidden email]> wrote:
> >
> >> Upgrade compatibility doesn't necessary mean that real organizations can
> >> perform the upgrade (I've seen my fair-share of reasons that
> >> organization cannot/will-not upgrade for some period of time). This
> >> typically has a minimum time-line of a couple of months to make and
> >> schedule the work.
> >>
> >>
> > True, and I can think of some reasons that would make my own life
> difficult
> > (dependency convergence in Fedora RPM packages might make it hard to
> update
> > to a new backwards-compatible version which has new dependencies).
> >
> > However, I'm also coming at this from some perspectives I've gotten from
> > users at $dayjob. When we released 1.7.3 and 1.8.1, several people
> emailed
> > me with some confusion, asking which one they should upgrade to. In
> > general, when people are considering such upgrades, I would simply
> > recommend the later one, so that's what I did... but then they asked me,
> > "Who exactly is 1.7.3 for, then?" and I couldn't really think of an
> answer
> > I thought was a good one. For most people... either you can upgrade or
> you
> > can't. If you can upgrade, upgrade to the latest one which is compatible.
> > If you can't upgrade, then why care about 1.7.3?
> >
> > I realize there's some cases, where upgrading to 1.7.3 is easy, but 1.8.1
> > is harder... my own example above. But, from my understanding of how most
> > users package and deploy Accumulo with bundled dependencies, I can't
> > imagine many scenarios where there's a reason to upgrade only to 1.7.3
> > instead of going to 1.8.1, except that we, as developers have provided
> that
> > option... some there may be some perceptions that the larger jump is
> > riskier in some way (when that's not necessarily the case, especially
> once
> > the new line has had a chance to have been shown to be stable).
> >
> > The user confusion is exacerbated by the fact that sometimes the release
> > timing results in the earlier release line having bug fixes which have
> not
> > yet made it in to the newer release line. And, our motivation to do a new
> > release in the newer line is lowered from having recently done two prior
> > releases. If we weren't doing new bugfixes in the previous line after the
> > latest has stabilized, there'd probably be more motivation to do more
> > bugfix releases in the latest line.
> >
> >
> >> I assume we have no idea about who is using what version -- sending a
> >> note to users@ would might generate some helpful feedback. We could
> also
> >> look at known downstream integrations to see if they have done 1.8
> >> testing (e.g. Pig, Hive, Presto), if nothing else, to let them all know
> >> "change is a'coming".
> >>
> >>
> > Is there any chance you'd be willing to pose some questions to the user
> > list to solicit some feedback? I fear that I won't be able to frame the
> > questions well enough to get the kind of feedback we need to decide on
> > something like this.
> >
> >
> >
> >> As a developer, I'd like to retire 1.7, but I'm not sure if it's
> >> realistic yet. Regardless, this conversation is certainly a good idea.
> >>
> >>
> >> On 6/1/17 6:33 PM, Christopher wrote:
> >> > Now that we do semver, and 1.8 has been broken in a bit, do we need to
> >> > continue to support 1.7 releases with bugfixes? There is a fully
> >> > backwards-compatible upgrade path from 1.7 to 1.8. So, it seems we
> >> probably
> >> > don't need to support new 1.7.x to 1.7.(x+1) upgrade paths any more.
> >> >
> >> > Not sure. Thoughts?
> >> >
> >>
>
>
>
> --
> busbey
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Sean Busbey
On Mon, Jun 5, 2017 at 11:12 AM, Christopher <[hidden email]> wrote:

> On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <[hidden email]> wrote:
>
>> Many users in enterprise spaces have rules for upgrading to
>> a new maintenance release that are different from upgrading to a new
>> minor release. Those rules presume a uniform understanding of the
>> risks involved in each of those kinds of releases that I don't think
>> exists, especially across open source projects, but nonetheless those
>> are the rules the organization is stuck with. For those users,
>> continued maintenance releases that include critical bug fixes are key
>> to allowing them to consume our releases.
>>
>>
> I agree that occurs, but I also think that such rules in enterprises don't
> exist in a vacuum. They exist in the context of what the project itself is
> doing. Choosing to upgrade to a new maintenance release is only an option
> when the upstream project is still producing maintenance releases. Since
> that's at the core of what this discussion is about, the question becomes
> something like "If we do this, will we be encouraging [enterprise and
> other] users to use the latest minor.patch release on their next upgrade
> cycle, or are we discouraging them from upgrading at all?" I don't know the
> answer, but if it's the latter, the next question is "Can we correct for
> any misperceived risks by better communicating what we know about upgrade
> risks to newer minor versions?" I don't know the answer to that question,
> either.
>
> In my experience with my "enterprise" customers, the reluctance to upgrade
> seems to apply equally to all versions. I recently provided support to
> somebody still running 1.5.0, in spite of the 1.5 line being on 1.5.4 and
> *very* EOL, because of reluctance to upgrade.
>

In my limited experience, when ASF projects don't reliably make
maintenance releases, enterprise customers turn to vendors to provide
a source of conservative updates. Phrased another way, it's a thing
that I see pointed to for why a decision maker might pick a vendor
"powered by" an asf project rather than asf blessed releases.

--
busbey
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Christopher Tubbs-2
On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <[hidden email]> wrote:

> On Mon, Jun 5, 2017 at 11:12 AM, Christopher <[hidden email]> wrote:
> > On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <[hidden email]> wrote:
> >
> >> Many users in enterprise spaces have rules for upgrading to
> >> a new maintenance release that are different from upgrading to a new
> >> minor release. Those rules presume a uniform understanding of the
> >> risks involved in each of those kinds of releases that I don't think
> >> exists, especially across open source projects, but nonetheless those
> >> are the rules the organization is stuck with. For those users,
> >> continued maintenance releases that include critical bug fixes are key
> >> to allowing them to consume our releases.
> >>
> >>
> > I agree that occurs, but I also think that such rules in enterprises
> don't
> > exist in a vacuum. They exist in the context of what the project itself
> is
> > doing. Choosing to upgrade to a new maintenance release is only an option
> > when the upstream project is still producing maintenance releases. Since
> > that's at the core of what this discussion is about, the question becomes
> > something like "If we do this, will we be encouraging [enterprise and
> > other] users to use the latest minor.patch release on their next upgrade
> > cycle, or are we discouraging them from upgrading at all?" I don't know
> the
> > answer, but if it's the latter, the next question is "Can we correct for
> > any misperceived risks by better communicating what we know about upgrade
> > risks to newer minor versions?" I don't know the answer to that question,
> > either.
> >
> > In my experience with my "enterprise" customers, the reluctance to
> upgrade
> > seems to apply equally to all versions. I recently provided support to
> > somebody still running 1.5.0, in spite of the 1.5 line being on 1.5.4 and
> > *very* EOL, because of reluctance to upgrade.
> >
>
> In my limited experience, when ASF projects don't reliably make
> maintenance releases, enterprise customers turn to vendors to provide
> a source of conservative updates. Phrased another way, it's a thing
> that I see pointed to for why a decision maker might pick a vendor
> "powered by" an asf project rather than asf blessed releases.
>
>
I've seen that, too. Are you suggesting that's a problem?

I'm interested in providing more frequent releases on fewer maintenance
branches. But, if a vendor wants to provide an alternate upgrade path to
fill a specific need for users with special requirements for earlier
branches, I think that's fine.
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Mike Walch-2
This debate seems to come up frequently and the viewpoints expressed seem
to represent one of two groups of Accumulo users:

1. conservative, enterprise users that want to avoid upgrades and want
long-term support.
2. early adopters and developers that want frequent minor releases as they
are willing to upgrade and don't care about long-term support.

I think our goal should be keep both groups happy as enterprise users
typically pay the bills and early adopters/developers help test out new
releases and features.

Currently, we advertise a 1.6, 1.7, and 1.8 release on our downloads page.
If I was an enterprise user, I would not know which release to use or
upgrade to.  I think we should instead identify certain minor releases as
long-term support releases (LTS) (like Ubuntu) and push enterprise users to
use them.

Our website and downloads push could advertise the latest release and the
latest LTS release.  This could allow us to minimize the number of
maintenance branches by only supporting the latest minor release branch and
latest LTS branch.  For example, if our latest release is 2.2.0, we can
drop support for the 2.0 & 2.1 branches but support new bugfix releases on
the 2.2 and 1.8 branches.

If the 2.2 branch is identified as the next LTS branch, we could develop an
easy upgrade script for enterprise users to go directly from 1.8 to 2.2
(skipping 2.0, 2.1).

On Mon, Jun 5, 2017 at 3:12 PM Christopher <[hidden email]> wrote:

> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <[hidden email]> wrote:
>
> > On Mon, Jun 5, 2017 at 11:12 AM, Christopher <[hidden email]>
> wrote:
> > > On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <[hidden email]>
> wrote:
> > >
> > >> Many users in enterprise spaces have rules for upgrading to
> > >> a new maintenance release that are different from upgrading to a new
> > >> minor release. Those rules presume a uniform understanding of the
> > >> risks involved in each of those kinds of releases that I don't think
> > >> exists, especially across open source projects, but nonetheless those
> > >> are the rules the organization is stuck with. For those users,
> > >> continued maintenance releases that include critical bug fixes are key
> > >> to allowing them to consume our releases.
> > >>
> > >>
> > > I agree that occurs, but I also think that such rules in enterprises
> > don't
> > > exist in a vacuum. They exist in the context of what the project itself
> > is
> > > doing. Choosing to upgrade to a new maintenance release is only an
> option
> > > when the upstream project is still producing maintenance releases.
> Since
> > > that's at the core of what this discussion is about, the question
> becomes
> > > something like "If we do this, will we be encouraging [enterprise and
> > > other] users to use the latest minor.patch release on their next
> upgrade
> > > cycle, or are we discouraging them from upgrading at all?" I don't know
> > the
> > > answer, but if it's the latter, the next question is "Can we correct
> for
> > > any misperceived risks by better communicating what we know about
> upgrade
> > > risks to newer minor versions?" I don't know the answer to that
> question,
> > > either.
> > >
> > > In my experience with my "enterprise" customers, the reluctance to
> > upgrade
> > > seems to apply equally to all versions. I recently provided support to
> > > somebody still running 1.5.0, in spite of the 1.5 line being on 1.5.4
> and
> > > *very* EOL, because of reluctance to upgrade.
> > >
> >
> > In my limited experience, when ASF projects don't reliably make
> > maintenance releases, enterprise customers turn to vendors to provide
> > a source of conservative updates. Phrased another way, it's a thing
> > that I see pointed to for why a decision maker might pick a vendor
> > "powered by" an asf project rather than asf blessed releases.
> >
> >
> I've seen that, too. Are you suggesting that's a problem?
>
> I'm interested in providing more frequent releases on fewer maintenance
> branches. But, if a vendor wants to provide an alternate upgrade path to
> fill a specific need for users with special requirements for earlier
> branches, I think that's fine.
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Mike Walch-2
My examples in my last email assume that 1.8 is the first LTS branch.  I
think this makes sense as 1.8 should be the last 1.x release.

On Mon, Jun 5, 2017 at 4:52 PM Mike Walch <[hidden email]> wrote:

> This debate seems to come up frequently and the viewpoints expressed seem
> to represent one of two groups of Accumulo users:
>
> 1. conservative, enterprise users that want to avoid upgrades and want
> long-term support.
> 2. early adopters and developers that want frequent minor releases as they
> are willing to upgrade and don't care about long-term support.
>
> I think our goal should be keep both groups happy as enterprise users
> typically pay the bills and early adopters/developers help test out new
> releases and features.
>
> Currently, we advertise a 1.6, 1.7, and 1.8 release on our downloads page.
> If I was an enterprise user, I would not know which release to use or
> upgrade to.  I think we should instead identify certain minor releases as
> long-term support releases (LTS) (like Ubuntu) and push enterprise users to
> use them.
>
> Our website and downloads push could advertise the latest release and the
> latest LTS release.  This could allow us to minimize the number of
> maintenance branches by only supporting the latest minor release branch and
> latest LTS branch.  For example, if our latest release is 2.2.0, we can
> drop support for the 2.0 & 2.1 branches but support new bugfix releases on
> the 2.2 and 1.8 branches.
>
> If the 2.2 branch is identified as the next LTS branch, we could develop
> an easy upgrade script for enterprise users to go directly from 1.8 to 2.2
> (skipping 2.0, 2.1).
>
> On Mon, Jun 5, 2017 at 3:12 PM Christopher <[hidden email]> wrote:
>
>> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <[hidden email]> wrote:
>>
>> > On Mon, Jun 5, 2017 at 11:12 AM, Christopher <[hidden email]>
>> wrote:
>> > > On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <[hidden email]>
>> wrote:
>> > >
>> > >> Many users in enterprise spaces have rules for upgrading to
>> > >> a new maintenance release that are different from upgrading to a new
>> > >> minor release. Those rules presume a uniform understanding of the
>> > >> risks involved in each of those kinds of releases that I don't think
>> > >> exists, especially across open source projects, but nonetheless those
>> > >> are the rules the organization is stuck with. For those users,
>> > >> continued maintenance releases that include critical bug fixes are
>> key
>> > >> to allowing them to consume our releases.
>> > >>
>> > >>
>> > > I agree that occurs, but I also think that such rules in enterprises
>> > don't
>> > > exist in a vacuum. They exist in the context of what the project
>> itself
>> > is
>> > > doing. Choosing to upgrade to a new maintenance release is only an
>> option
>> > > when the upstream project is still producing maintenance releases.
>> Since
>> > > that's at the core of what this discussion is about, the question
>> becomes
>> > > something like "If we do this, will we be encouraging [enterprise and
>> > > other] users to use the latest minor.patch release on their next
>> upgrade
>> > > cycle, or are we discouraging them from upgrading at all?" I don't
>> know
>> > the
>> > > answer, but if it's the latter, the next question is "Can we correct
>> for
>> > > any misperceived risks by better communicating what we know about
>> upgrade
>> > > risks to newer minor versions?" I don't know the answer to that
>> question,
>> > > either.
>> > >
>> > > In my experience with my "enterprise" customers, the reluctance to
>> > upgrade
>> > > seems to apply equally to all versions. I recently provided support to
>> > > somebody still running 1.5.0, in spite of the 1.5 line being on 1.5.4
>> and
>> > > *very* EOL, because of reluctance to upgrade.
>> > >
>> >
>> > In my limited experience, when ASF projects don't reliably make
>> > maintenance releases, enterprise customers turn to vendors to provide
>> > a source of conservative updates. Phrased another way, it's a thing
>> > that I see pointed to for why a decision maker might pick a vendor
>> > "powered by" an asf project rather than asf blessed releases.
>> >
>> >
>> I've seen that, too. Are you suggesting that's a problem?
>>
>> I'm interested in providing more frequent releases on fewer maintenance
>> branches. But, if a vendor wants to provide an alternate upgrade path to
>> fill a specific need for users with special requirements for earlier
>> branches, I think that's fine.
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Sean Busbey
In reply to this post by Christopher Tubbs-2
On Mon, Jun 5, 2017 at 2:12 PM, Christopher <[hidden email]> wrote:

> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <[hidden email]> wrote:
>
>>
>> In my limited experience, when ASF projects don't reliably make
>> maintenance releases, enterprise customers turn to vendors to provide
>> a source of conservative updates. Phrased another way, it's a thing
>> that I see pointed to for why a decision maker might pick a vendor
>> "powered by" an asf project rather than asf blessed releases.
>>
>>
> I've seen that, too. Are you suggesting that's a problem?
>
> I'm interested in providing more frequent releases on fewer maintenance
> branches. But, if a vendor wants to provide an alternate upgrade path to
> fill a specific need for users with special requirements for earlier
> branches, I think that's fine.

Yeah, I generally consider it a problem. It cuts off a part of our
potential community funnel for increasing participation. What
incentive is there for the folks working on/with Accumulo at Big Co,
Inc to engage with us here if they have to wait for Vendor Y to
actually get their changes into a format they can make use of?

--
busbey
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Sean Busbey
In reply to this post by Mike Walch-2
We should remove the 1.6 stuff, since it went EOM back in September 2016.

FWIW, all the folks I have visibility into are running either 1.4 (I
know... :( ), 1.6, or 1.7. Granted this is biased by the fact that the
vast majority (but not all) are relying on something "Powered By"
those apache release versions and the provider of those "powered by"
bits don't offer anything based on 1.8.

I like the idea of having a LTS branch. Something analogous to what
I've seen other communities do by designating a "current stable"
release line that's expected to keep getting updates for longer. It
makes it easy to guide most folks towards using that version.

Another possibility is to change how we structure application of fixes
so that every developer doesn't have to deal with every active branch.
Apache Avro, for example, historically just had everyone patch to the
trunk branch and left it up to release managers to cherry pick back to
active release lines.

On Mon, Jun 5, 2017 at 4:01 PM, Mike Walch <[hidden email]> wrote:

> My examples in my last email assume that 1.8 is the first LTS branch.  I
> think this makes sense as 1.8 should be the last 1.x release.
>
> On Mon, Jun 5, 2017 at 4:52 PM Mike Walch <[hidden email]> wrote:
>
>> This debate seems to come up frequently and the viewpoints expressed seem
>> to represent one of two groups of Accumulo users:
>>
>> 1. conservative, enterprise users that want to avoid upgrades and want
>> long-term support.
>> 2. early adopters and developers that want frequent minor releases as they
>> are willing to upgrade and don't care about long-term support.
>>
>> I think our goal should be keep both groups happy as enterprise users
>> typically pay the bills and early adopters/developers help test out new
>> releases and features.
>>
>> Currently, we advertise a 1.6, 1.7, and 1.8 release on our downloads page.
>> If I was an enterprise user, I would not know which release to use or
>> upgrade to.  I think we should instead identify certain minor releases as
>> long-term support releases (LTS) (like Ubuntu) and push enterprise users to
>> use them.
>>
>> Our website and downloads push could advertise the latest release and the
>> latest LTS release.  This could allow us to minimize the number of
>> maintenance branches by only supporting the latest minor release branch and
>> latest LTS branch.  For example, if our latest release is 2.2.0, we can
>> drop support for the 2.0 & 2.1 branches but support new bugfix releases on
>> the 2.2 and 1.8 branches.
>>
>> If the 2.2 branch is identified as the next LTS branch, we could develop
>> an easy upgrade script for enterprise users to go directly from 1.8 to 2.2
>> (skipping 2.0, 2.1).
>>
>> On Mon, Jun 5, 2017 at 3:12 PM Christopher <[hidden email]> wrote:
>>
>>> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <[hidden email]> wrote:
>>>
>>> > On Mon, Jun 5, 2017 at 11:12 AM, Christopher <[hidden email]>
>>> wrote:
>>> > > On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <[hidden email]>
>>> wrote:
>>> > >
>>> > >> Many users in enterprise spaces have rules for upgrading to
>>> > >> a new maintenance release that are different from upgrading to a new
>>> > >> minor release. Those rules presume a uniform understanding of the
>>> > >> risks involved in each of those kinds of releases that I don't think
>>> > >> exists, especially across open source projects, but nonetheless those
>>> > >> are the rules the organization is stuck with. For those users,
>>> > >> continued maintenance releases that include critical bug fixes are
>>> key
>>> > >> to allowing them to consume our releases.
>>> > >>
>>> > >>
>>> > > I agree that occurs, but I also think that such rules in enterprises
>>> > don't
>>> > > exist in a vacuum. They exist in the context of what the project
>>> itself
>>> > is
>>> > > doing. Choosing to upgrade to a new maintenance release is only an
>>> option
>>> > > when the upstream project is still producing maintenance releases.
>>> Since
>>> > > that's at the core of what this discussion is about, the question
>>> becomes
>>> > > something like "If we do this, will we be encouraging [enterprise and
>>> > > other] users to use the latest minor.patch release on their next
>>> upgrade
>>> > > cycle, or are we discouraging them from upgrading at all?" I don't
>>> know
>>> > the
>>> > > answer, but if it's the latter, the next question is "Can we correct
>>> for
>>> > > any misperceived risks by better communicating what we know about
>>> upgrade
>>> > > risks to newer minor versions?" I don't know the answer to that
>>> question,
>>> > > either.
>>> > >
>>> > > In my experience with my "enterprise" customers, the reluctance to
>>> > upgrade
>>> > > seems to apply equally to all versions. I recently provided support to
>>> > > somebody still running 1.5.0, in spite of the 1.5 line being on 1.5.4
>>> and
>>> > > *very* EOL, because of reluctance to upgrade.
>>> > >
>>> >
>>> > In my limited experience, when ASF projects don't reliably make
>>> > maintenance releases, enterprise customers turn to vendors to provide
>>> > a source of conservative updates. Phrased another way, it's a thing
>>> > that I see pointed to for why a decision maker might pick a vendor
>>> > "powered by" an asf project rather than asf blessed releases.
>>> >
>>> >
>>> I've seen that, too. Are you suggesting that's a problem?
>>>
>>> I'm interested in providing more frequent releases on fewer maintenance
>>> branches. But, if a vendor wants to provide an alternate upgrade path to
>>> fill a specific need for users with special requirements for earlier
>>> branches, I think that's fine.
>>>
>>



--
busbey
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Christopher Tubbs-2
The way I think about it, the 1.x line is our LTS release, not a specific
minor release within 1.x (at least, since we starting guaranteeing
backwards compatibility). This is because even in LTS models like Ubuntu or
RHEL, new features are added if they are backwards-compatible. This is why
I think we're possibly not doing a good enough job at declaring that the
newer minor releases in 1.x can/should be upgraded to once we think they're
stable. This is a bit like the RHEL model. The "LTS" release is RHEL 7, and
maintenance effectively stops on 7.2 once 7.3 is released, because the
patch process becomes "update to 7.3". Most people wouldn't consider an
upgrade from 7.2 to 7.3 a risky update, because of the delivery mechanism
(patch releases... updates to specific RPMs... are delivered the same way
as minor releases: yum update). So, in a sense, I think the reason we're
having this discussion is because we don't have a good "delivery mechanism"
to ensure upgrade confidence to the next minor release. The analogy isn't
perfect, but hopefully that gives a hint at how I'm thinking about "LTS".
Major releases seem to be a natural demarcation point for me for the "LTS"
concept.

What it really comes down to for me, is "what is the upgrade path?" And, I
think our current model of having so many, sometimes inconsistent (due to
timing of releases), upgrade paths isn't very efficient, is potentially
confusing, and I worry that it's inhibiting the goal that we all seem to
agree needs to happen: more frequent patch releases.

Currently, our de facto support mechanism is the "last 2 minor releases"
(dev minus 1, dev minus 2).
I opened this conversation suggesting that, perhaps, it is better to switch
to "last 1 minor releases (once stable)" (dev-1).
A middle-ground might be: "last 1 minor release (once stable) for routine
patches + last 2 minor releases for critical or on-demand patches". (dev-1,
dev-2*).

The way that middle ground might work is: we clean up JIRA so that we don't
have to keep bumping issues which aren't being worked on (dev-2). Instead
of starting patches at (dev-2), merging into (dev-1), and then into
(dev/master), we start at (dev-1). If it's a critical issue, we'll probably
want to start at (dev-2). If somebody contributes specifically because they
need/want something fixed in (dev-2), we encourage them to do so, and take
the opportunity to on-board a new committer as that patch is applied and
released. We won't say "no" to (dev-2) patches and releases, but we don't
have to require every routine patch start that far back, either. Patches
can always be backported to (dev-2) on-demand if somebody is willing to
champion it.


On Mon, Jun 5, 2017 at 5:43 PM Sean Busbey <[hidden email]> wrote:

> We should remove the 1.6 stuff, since it went EOM back in September 2016.
>
> FWIW, all the folks I have visibility into are running either 1.4 (I
> know... :( ), 1.6, or 1.7. Granted this is biased by the fact that the
> vast majority (but not all) are relying on something "Powered By"
> those apache release versions and the provider of those "powered by"
> bits don't offer anything based on 1.8.
>
> I like the idea of having a LTS branch. Something analogous to what
> I've seen other communities do by designating a "current stable"
> release line that's expected to keep getting updates for longer. It
> makes it easy to guide most folks towards using that version.
>
> Another possibility is to change how we structure application of fixes
> so that every developer doesn't have to deal with every active branch.
> Apache Avro, for example, historically just had everyone patch to the
> trunk branch and left it up to release managers to cherry pick back to
> active release lines.
>
> On Mon, Jun 5, 2017 at 4:01 PM, Mike Walch <[hidden email]> wrote:
> > My examples in my last email assume that 1.8 is the first LTS branch.  I
> > think this makes sense as 1.8 should be the last 1.x release.
> >
> > On Mon, Jun 5, 2017 at 4:52 PM Mike Walch <[hidden email]> wrote:
> >
> >> This debate seems to come up frequently and the viewpoints expressed
> seem
> >> to represent one of two groups of Accumulo users:
> >>
> >> 1. conservative, enterprise users that want to avoid upgrades and want
> >> long-term support.
> >> 2. early adopters and developers that want frequent minor releases as
> they
> >> are willing to upgrade and don't care about long-term support.
> >>
> >> I think our goal should be keep both groups happy as enterprise users
> >> typically pay the bills and early adopters/developers help test out new
> >> releases and features.
> >>
> >> Currently, we advertise a 1.6, 1.7, and 1.8 release on our downloads
> page.
> >> If I was an enterprise user, I would not know which release to use or
> >> upgrade to.  I think we should instead identify certain minor releases
> as
> >> long-term support releases (LTS) (like Ubuntu) and push enterprise
> users to
> >> use them.
> >>
> >> Our website and downloads push could advertise the latest release and
> the
> >> latest LTS release.  This could allow us to minimize the number of
> >> maintenance branches by only supporting the latest minor release branch
> and
> >> latest LTS branch.  For example, if our latest release is 2.2.0, we can
> >> drop support for the 2.0 & 2.1 branches but support new bugfix releases
> on
> >> the 2.2 and 1.8 branches.
> >>
> >> If the 2.2 branch is identified as the next LTS branch, we could develop
> >> an easy upgrade script for enterprise users to go directly from 1.8 to
> 2.2
> >> (skipping 2.0, 2.1).
> >>
> >> On Mon, Jun 5, 2017 at 3:12 PM Christopher <[hidden email]> wrote:
> >>
> >>> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <[hidden email]>
> wrote:
> >>>
> >>> > On Mon, Jun 5, 2017 at 11:12 AM, Christopher <[hidden email]>
> >>> wrote:
> >>> > > On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <[hidden email]>
> >>> wrote:
> >>> > >
> >>> > >> Many users in enterprise spaces have rules for upgrading to
> >>> > >> a new maintenance release that are different from upgrading to a
> new
> >>> > >> minor release. Those rules presume a uniform understanding of the
> >>> > >> risks involved in each of those kinds of releases that I don't
> think
> >>> > >> exists, especially across open source projects, but nonetheless
> those
> >>> > >> are the rules the organization is stuck with. For those users,
> >>> > >> continued maintenance releases that include critical bug fixes are
> >>> key
> >>> > >> to allowing them to consume our releases.
> >>> > >>
> >>> > >>
> >>> > > I agree that occurs, but I also think that such rules in
> enterprises
> >>> > don't
> >>> > > exist in a vacuum. They exist in the context of what the project
> >>> itself
> >>> > is
> >>> > > doing. Choosing to upgrade to a new maintenance release is only an
> >>> option
> >>> > > when the upstream project is still producing maintenance releases.
> >>> Since
> >>> > > that's at the core of what this discussion is about, the question
> >>> becomes
> >>> > > something like "If we do this, will we be encouraging [enterprise
> and
> >>> > > other] users to use the latest minor.patch release on their next
> >>> upgrade
> >>> > > cycle, or are we discouraging them from upgrading at all?" I don't
> >>> know
> >>> > the
> >>> > > answer, but if it's the latter, the next question is "Can we
> correct
> >>> for
> >>> > > any misperceived risks by better communicating what we know about
> >>> upgrade
> >>> > > risks to newer minor versions?" I don't know the answer to that
> >>> question,
> >>> > > either.
> >>> > >
> >>> > > In my experience with my "enterprise" customers, the reluctance to
> >>> > upgrade
> >>> > > seems to apply equally to all versions. I recently provided
> support to
> >>> > > somebody still running 1.5.0, in spite of the 1.5 line being on
> 1.5.4
> >>> and
> >>> > > *very* EOL, because of reluctance to upgrade.
> >>> > >
> >>> >
> >>> > In my limited experience, when ASF projects don't reliably make
> >>> > maintenance releases, enterprise customers turn to vendors to provide
> >>> > a source of conservative updates. Phrased another way, it's a thing
> >>> > that I see pointed to for why a decision maker might pick a vendor
> >>> > "powered by" an asf project rather than asf blessed releases.
> >>> >
> >>> >
> >>> I've seen that, too. Are you suggesting that's a problem?
> >>>
> >>> I'm interested in providing more frequent releases on fewer maintenance
> >>> branches. But, if a vendor wants to provide an alternate upgrade path
> to
> >>> fill a specific need for users with special requirements for earlier
> >>> branches, I think that's fine.
> >>>
> >>
>
>
>
> --
> busbey
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Mike Drob-4
As a specific example of folks looking at 1.7.3 as stable and seeing 1.8.x
as unstable, we have a current thread on the dev list -
https://lists.apache.org/thread.html/6e83fc644437c41ace5847d1cd5622f8174f7e0f8dfd1a30a8fd7116@%3Cdev.accumulo.apache.org%3E

Right or wrong, that's the way things are right now.

On Mon, Jun 5, 2017 at 5:52 PM, Christopher <[hidden email]> wrote:

> The way I think about it, the 1.x line is our LTS release, not a specific
> minor release within 1.x (at least, since we starting guaranteeing
> backwards compatibility). This is because even in LTS models like Ubuntu or
> RHEL, new features are added if they are backwards-compatible. This is why
> I think we're possibly not doing a good enough job at declaring that the
> newer minor releases in 1.x can/should be upgraded to once we think they're
> stable. This is a bit like the RHEL model. The "LTS" release is RHEL 7, and
> maintenance effectively stops on 7.2 once 7.3 is released, because the
> patch process becomes "update to 7.3". Most people wouldn't consider an
> upgrade from 7.2 to 7.3 a risky update, because of the delivery mechanism
> (patch releases... updates to specific RPMs... are delivered the same way
> as minor releases: yum update). So, in a sense, I think the reason we're
> having this discussion is because we don't have a good "delivery mechanism"
> to ensure upgrade confidence to the next minor release. The analogy isn't
> perfect, but hopefully that gives a hint at how I'm thinking about "LTS".
> Major releases seem to be a natural demarcation point for me for the "LTS"
> concept.
>
> What it really comes down to for me, is "what is the upgrade path?" And, I
> think our current model of having so many, sometimes inconsistent (due to
> timing of releases), upgrade paths isn't very efficient, is potentially
> confusing, and I worry that it's inhibiting the goal that we all seem to
> agree needs to happen: more frequent patch releases.
>
> Currently, our de facto support mechanism is the "last 2 minor releases"
> (dev minus 1, dev minus 2).
> I opened this conversation suggesting that, perhaps, it is better to switch
> to "last 1 minor releases (once stable)" (dev-1).
> A middle-ground might be: "last 1 minor release (once stable) for routine
> patches + last 2 minor releases for critical or on-demand patches". (dev-1,
> dev-2*).
>
> The way that middle ground might work is: we clean up JIRA so that we don't
> have to keep bumping issues which aren't being worked on (dev-2). Instead
> of starting patches at (dev-2), merging into (dev-1), and then into
> (dev/master), we start at (dev-1). If it's a critical issue, we'll probably
> want to start at (dev-2). If somebody contributes specifically because they
> need/want something fixed in (dev-2), we encourage them to do so, and take
> the opportunity to on-board a new committer as that patch is applied and
> released. We won't say "no" to (dev-2) patches and releases, but we don't
> have to require every routine patch start that far back, either. Patches
> can always be backported to (dev-2) on-demand if somebody is willing to
> champion it.
>
>
> On Mon, Jun 5, 2017 at 5:43 PM Sean Busbey <[hidden email]> wrote:
>
> > We should remove the 1.6 stuff, since it went EOM back in September 2016.
> >
> > FWIW, all the folks I have visibility into are running either 1.4 (I
> > know... :( ), 1.6, or 1.7. Granted this is biased by the fact that the
> > vast majority (but not all) are relying on something "Powered By"
> > those apache release versions and the provider of those "powered by"
> > bits don't offer anything based on 1.8.
> >
> > I like the idea of having a LTS branch. Something analogous to what
> > I've seen other communities do by designating a "current stable"
> > release line that's expected to keep getting updates for longer. It
> > makes it easy to guide most folks towards using that version.
> >
> > Another possibility is to change how we structure application of fixes
> > so that every developer doesn't have to deal with every active branch.
> > Apache Avro, for example, historically just had everyone patch to the
> > trunk branch and left it up to release managers to cherry pick back to
> > active release lines.
> >
> > On Mon, Jun 5, 2017 at 4:01 PM, Mike Walch <[hidden email]> wrote:
> > > My examples in my last email assume that 1.8 is the first LTS branch.
> I
> > > think this makes sense as 1.8 should be the last 1.x release.
> > >
> > > On Mon, Jun 5, 2017 at 4:52 PM Mike Walch <[hidden email]> wrote:
> > >
> > >> This debate seems to come up frequently and the viewpoints expressed
> > seem
> > >> to represent one of two groups of Accumulo users:
> > >>
> > >> 1. conservative, enterprise users that want to avoid upgrades and want
> > >> long-term support.
> > >> 2. early adopters and developers that want frequent minor releases as
> > they
> > >> are willing to upgrade and don't care about long-term support.
> > >>
> > >> I think our goal should be keep both groups happy as enterprise users
> > >> typically pay the bills and early adopters/developers help test out
> new
> > >> releases and features.
> > >>
> > >> Currently, we advertise a 1.6, 1.7, and 1.8 release on our downloads
> > page.
> > >> If I was an enterprise user, I would not know which release to use or
> > >> upgrade to.  I think we should instead identify certain minor releases
> > as
> > >> long-term support releases (LTS) (like Ubuntu) and push enterprise
> > users to
> > >> use them.
> > >>
> > >> Our website and downloads push could advertise the latest release and
> > the
> > >> latest LTS release.  This could allow us to minimize the number of
> > >> maintenance branches by only supporting the latest minor release
> branch
> > and
> > >> latest LTS branch.  For example, if our latest release is 2.2.0, we
> can
> > >> drop support for the 2.0 & 2.1 branches but support new bugfix
> releases
> > on
> > >> the 2.2 and 1.8 branches.
> > >>
> > >> If the 2.2 branch is identified as the next LTS branch, we could
> develop
> > >> an easy upgrade script for enterprise users to go directly from 1.8 to
> > 2.2
> > >> (skipping 2.0, 2.1).
> > >>
> > >> On Mon, Jun 5, 2017 at 3:12 PM Christopher <[hidden email]>
> wrote:
> > >>
> > >>> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <[hidden email]>
> > wrote:
> > >>>
> > >>> > On Mon, Jun 5, 2017 at 11:12 AM, Christopher <[hidden email]>
> > >>> wrote:
> > >>> > > On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <[hidden email]
> >
> > >>> wrote:
> > >>> > >
> > >>> > >> Many users in enterprise spaces have rules for upgrading to
> > >>> > >> a new maintenance release that are different from upgrading to a
> > new
> > >>> > >> minor release. Those rules presume a uniform understanding of
> the
> > >>> > >> risks involved in each of those kinds of releases that I don't
> > think
> > >>> > >> exists, especially across open source projects, but nonetheless
> > those
> > >>> > >> are the rules the organization is stuck with. For those users,
> > >>> > >> continued maintenance releases that include critical bug fixes
> are
> > >>> key
> > >>> > >> to allowing them to consume our releases.
> > >>> > >>
> > >>> > >>
> > >>> > > I agree that occurs, but I also think that such rules in
> > enterprises
> > >>> > don't
> > >>> > > exist in a vacuum. They exist in the context of what the project
> > >>> itself
> > >>> > is
> > >>> > > doing. Choosing to upgrade to a new maintenance release is only
> an
> > >>> option
> > >>> > > when the upstream project is still producing maintenance
> releases.
> > >>> Since
> > >>> > > that's at the core of what this discussion is about, the question
> > >>> becomes
> > >>> > > something like "If we do this, will we be encouraging [enterprise
> > and
> > >>> > > other] users to use the latest minor.patch release on their next
> > >>> upgrade
> > >>> > > cycle, or are we discouraging them from upgrading at all?" I
> don't
> > >>> know
> > >>> > the
> > >>> > > answer, but if it's the latter, the next question is "Can we
> > correct
> > >>> for
> > >>> > > any misperceived risks by better communicating what we know about
> > >>> upgrade
> > >>> > > risks to newer minor versions?" I don't know the answer to that
> > >>> question,
> > >>> > > either.
> > >>> > >
> > >>> > > In my experience with my "enterprise" customers, the reluctance
> to
> > >>> > upgrade
> > >>> > > seems to apply equally to all versions. I recently provided
> > support to
> > >>> > > somebody still running 1.5.0, in spite of the 1.5 line being on
> > 1.5.4
> > >>> and
> > >>> > > *very* EOL, because of reluctance to upgrade.
> > >>> > >
> > >>> >
> > >>> > In my limited experience, when ASF projects don't reliably make
> > >>> > maintenance releases, enterprise customers turn to vendors to
> provide
> > >>> > a source of conservative updates. Phrased another way, it's a thing
> > >>> > that I see pointed to for why a decision maker might pick a vendor
> > >>> > "powered by" an asf project rather than asf blessed releases.
> > >>> >
> > >>> >
> > >>> I've seen that, too. Are you suggesting that's a problem?
> > >>>
> > >>> I'm interested in providing more frequent releases on fewer
> maintenance
> > >>> branches. But, if a vendor wants to provide an alternate upgrade path
> > to
> > >>> fill a specific need for users with special requirements for earlier
> > >>> branches, I think that's fine.
> > >>>
> > >>
> >
> >
> >
> > --
> > busbey
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Marc
I'm not sure it would solve Bob's concern of having more "soak time," but
we could clarify that 1.8.1 is Stable.

The linux kernel makes the releases very clear:  https://www.kernel.org/

Do you think that presenting 1.8.1 as the stable branch will help? I see
the Releases dropdown shows 1.8.1 as 'Latest'. In my opinion that doesn't
serve 1.8.1 very well.

Some will believe it's too new to try regardless of nomenclature, but
personally I see Latest and think "let someone else try it first."

On Tue, Jun 6, 2017 at 12:02 PM, Mike Drob <[hidden email]> wrote:

> As a specific example of folks looking at 1.7.3 as stable and seeing 1.8.x
> as unstable, we have a current thread on the dev list -
> https://lists.apache.org/thread.html/6e83fc644437c41ace5847d1cd5622
> f8174f7e0f8dfd1a30a8fd7116@%3Cdev.accumulo.apache.org%3E
>
> Right or wrong, that's the way things are right now.
>
> On Mon, Jun 5, 2017 at 5:52 PM, Christopher <[hidden email]> wrote:
>
> > The way I think about it, the 1.x line is our LTS release, not a specific
> > minor release within 1.x (at least, since we starting guaranteeing
> > backwards compatibility). This is because even in LTS models like Ubuntu
> or
> > RHEL, new features are added if they are backwards-compatible. This is
> why
> > I think we're possibly not doing a good enough job at declaring that the
> > newer minor releases in 1.x can/should be upgraded to once we think
> they're
> > stable. This is a bit like the RHEL model. The "LTS" release is RHEL 7,
> and
> > maintenance effectively stops on 7.2 once 7.3 is released, because the
> > patch process becomes "update to 7.3". Most people wouldn't consider an
> > upgrade from 7.2 to 7.3 a risky update, because of the delivery mechanism
> > (patch releases... updates to specific RPMs... are delivered the same way
> > as minor releases: yum update). So, in a sense, I think the reason we're
> > having this discussion is because we don't have a good "delivery
> mechanism"
> > to ensure upgrade confidence to the next minor release. The analogy isn't
> > perfect, but hopefully that gives a hint at how I'm thinking about "LTS".
> > Major releases seem to be a natural demarcation point for me for the
> "LTS"
> > concept.
> >
> > What it really comes down to for me, is "what is the upgrade path?" And,
> I
> > think our current model of having so many, sometimes inconsistent (due to
> > timing of releases), upgrade paths isn't very efficient, is potentially
> > confusing, and I worry that it's inhibiting the goal that we all seem to
> > agree needs to happen: more frequent patch releases.
> >
> > Currently, our de facto support mechanism is the "last 2 minor releases"
> > (dev minus 1, dev minus 2).
> > I opened this conversation suggesting that, perhaps, it is better to
> switch
> > to "last 1 minor releases (once stable)" (dev-1).
> > A middle-ground might be: "last 1 minor release (once stable) for routine
> > patches + last 2 minor releases for critical or on-demand patches".
> (dev-1,
> > dev-2*).
> >
> > The way that middle ground might work is: we clean up JIRA so that we
> don't
> > have to keep bumping issues which aren't being worked on (dev-2). Instead
> > of starting patches at (dev-2), merging into (dev-1), and then into
> > (dev/master), we start at (dev-1). If it's a critical issue, we'll
> probably
> > want to start at (dev-2). If somebody contributes specifically because
> they
> > need/want something fixed in (dev-2), we encourage them to do so, and
> take
> > the opportunity to on-board a new committer as that patch is applied and
> > released. We won't say "no" to (dev-2) patches and releases, but we don't
> > have to require every routine patch start that far back, either. Patches
> > can always be backported to (dev-2) on-demand if somebody is willing to
> > champion it.
> >
> >
> > On Mon, Jun 5, 2017 at 5:43 PM Sean Busbey <[hidden email]> wrote:
> >
> > > We should remove the 1.6 stuff, since it went EOM back in September
> 2016.
> > >
> > > FWIW, all the folks I have visibility into are running either 1.4 (I
> > > know... :( ), 1.6, or 1.7. Granted this is biased by the fact that the
> > > vast majority (but not all) are relying on something "Powered By"
> > > those apache release versions and the provider of those "powered by"
> > > bits don't offer anything based on 1.8.
> > >
> > > I like the idea of having a LTS branch. Something analogous to what
> > > I've seen other communities do by designating a "current stable"
> > > release line that's expected to keep getting updates for longer. It
> > > makes it easy to guide most folks towards using that version.
> > >
> > > Another possibility is to change how we structure application of fixes
> > > so that every developer doesn't have to deal with every active branch.
> > > Apache Avro, for example, historically just had everyone patch to the
> > > trunk branch and left it up to release managers to cherry pick back to
> > > active release lines.
> > >
> > > On Mon, Jun 5, 2017 at 4:01 PM, Mike Walch <[hidden email]> wrote:
> > > > My examples in my last email assume that 1.8 is the first LTS branch.
> > I
> > > > think this makes sense as 1.8 should be the last 1.x release.
> > > >
> > > > On Mon, Jun 5, 2017 at 4:52 PM Mike Walch <[hidden email]> wrote:
> > > >
> > > >> This debate seems to come up frequently and the viewpoints expressed
> > > seem
> > > >> to represent one of two groups of Accumulo users:
> > > >>
> > > >> 1. conservative, enterprise users that want to avoid upgrades and
> want
> > > >> long-term support.
> > > >> 2. early adopters and developers that want frequent minor releases
> as
> > > they
> > > >> are willing to upgrade and don't care about long-term support.
> > > >>
> > > >> I think our goal should be keep both groups happy as enterprise
> users
> > > >> typically pay the bills and early adopters/developers help test out
> > new
> > > >> releases and features.
> > > >>
> > > >> Currently, we advertise a 1.6, 1.7, and 1.8 release on our downloads
> > > page.
> > > >> If I was an enterprise user, I would not know which release to use
> or
> > > >> upgrade to.  I think we should instead identify certain minor
> releases
> > > as
> > > >> long-term support releases (LTS) (like Ubuntu) and push enterprise
> > > users to
> > > >> use them.
> > > >>
> > > >> Our website and downloads push could advertise the latest release
> and
> > > the
> > > >> latest LTS release.  This could allow us to minimize the number of
> > > >> maintenance branches by only supporting the latest minor release
> > branch
> > > and
> > > >> latest LTS branch.  For example, if our latest release is 2.2.0, we
> > can
> > > >> drop support for the 2.0 & 2.1 branches but support new bugfix
> > releases
> > > on
> > > >> the 2.2 and 1.8 branches.
> > > >>
> > > >> If the 2.2 branch is identified as the next LTS branch, we could
> > develop
> > > >> an easy upgrade script for enterprise users to go directly from 1.8
> to
> > > 2.2
> > > >> (skipping 2.0, 2.1).
> > > >>
> > > >> On Mon, Jun 5, 2017 at 3:12 PM Christopher <[hidden email]>
> > wrote:
> > > >>
> > > >>> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <[hidden email]>
> > > wrote:
> > > >>>
> > > >>> > On Mon, Jun 5, 2017 at 11:12 AM, Christopher <
> [hidden email]>
> > > >>> wrote:
> > > >>> > > On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <
> [hidden email]
> > >
> > > >>> wrote:
> > > >>> > >
> > > >>> > >> Many users in enterprise spaces have rules for upgrading to
> > > >>> > >> a new maintenance release that are different from upgrading
> to a
> > > new
> > > >>> > >> minor release. Those rules presume a uniform understanding of
> > the
> > > >>> > >> risks involved in each of those kinds of releases that I don't
> > > think
> > > >>> > >> exists, especially across open source projects, but
> nonetheless
> > > those
> > > >>> > >> are the rules the organization is stuck with. For those users,
> > > >>> > >> continued maintenance releases that include critical bug fixes
> > are
> > > >>> key
> > > >>> > >> to allowing them to consume our releases.
> > > >>> > >>
> > > >>> > >>
> > > >>> > > I agree that occurs, but I also think that such rules in
> > > enterprises
> > > >>> > don't
> > > >>> > > exist in a vacuum. They exist in the context of what the
> project
> > > >>> itself
> > > >>> > is
> > > >>> > > doing. Choosing to upgrade to a new maintenance release is only
> > an
> > > >>> option
> > > >>> > > when the upstream project is still producing maintenance
> > releases.
> > > >>> Since
> > > >>> > > that's at the core of what this discussion is about, the
> question
> > > >>> becomes
> > > >>> > > something like "If we do this, will we be encouraging
> [enterprise
> > > and
> > > >>> > > other] users to use the latest minor.patch release on their
> next
> > > >>> upgrade
> > > >>> > > cycle, or are we discouraging them from upgrading at all?" I
> > don't
> > > >>> know
> > > >>> > the
> > > >>> > > answer, but if it's the latter, the next question is "Can we
> > > correct
> > > >>> for
> > > >>> > > any misperceived risks by better communicating what we know
> about
> > > >>> upgrade
> > > >>> > > risks to newer minor versions?" I don't know the answer to that
> > > >>> question,
> > > >>> > > either.
> > > >>> > >
> > > >>> > > In my experience with my "enterprise" customers, the reluctance
> > to
> > > >>> > upgrade
> > > >>> > > seems to apply equally to all versions. I recently provided
> > > support to
> > > >>> > > somebody still running 1.5.0, in spite of the 1.5 line being on
> > > 1.5.4
> > > >>> and
> > > >>> > > *very* EOL, because of reluctance to upgrade.
> > > >>> > >
> > > >>> >
> > > >>> > In my limited experience, when ASF projects don't reliably make
> > > >>> > maintenance releases, enterprise customers turn to vendors to
> > provide
> > > >>> > a source of conservative updates. Phrased another way, it's a
> thing
> > > >>> > that I see pointed to for why a decision maker might pick a
> vendor
> > > >>> > "powered by" an asf project rather than asf blessed releases.
> > > >>> >
> > > >>> >
> > > >>> I've seen that, too. Are you suggesting that's a problem?
> > > >>>
> > > >>> I'm interested in providing more frequent releases on fewer
> > maintenance
> > > >>> branches. But, if a vendor wants to provide an alternate upgrade
> path
> > > to
> > > >>> fill a specific need for users with special requirements for
> earlier
> > > >>> branches, I think that's fine.
> > > >>>
> > > >>
> > >
> > >
> > >
> > > --
> > > busbey
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Sean Busbey
Why do we consider 1.8.1 stable?

For example, has anyone done perf comparisons between 1.7 and 1.8.z?

When it came time for me to start telling folks that it was "safe" to
upgrade to 1.7.z I ran into something like a 40-60% perf degradation
on writes compared to 1.6 across the board. A little bit of this was
already fixed in 1.8 at the time, but a substantial amount required a
non-trivial refactoring because just no one had looked[1]. Even after
all of that, I still had to caveat things because I still saw a
~15-30% perf drop on random writes in the presence of lots of columns.

Also, attempting to check correctness via the RandomWalk test showed
that things had just stopped working on the 1.7 release line[2].
Reading the release notes for 1.8.z releases shows that no one has run
it as a part of 1.8.z RC testing[3]. Does it work now?

How polished are the features in 1.8.z? The work that went in to
getting kerberos for clients in the 1.7 line was great, but still
there were several fit-in-finish bits that came up a year and a half
into the 1.7 branch (minor deployment snags, some docs clarifications,
etc). Have we done a similar pass though the things we advertise in
1.8?

I don't mean for this to come across as a lot of complaining or
foisting work upon others. But if we're going to call something
"stable" as a project, these are the kinds of things the downstream
users I interact will will expect to have happened.


[1]: https://issues.apache.org/jira/browse/ACCUMULO-4458
[2]: https://issues.apache.org/jira/browse/ACCUMULO-4467
[3]:

http://accumulo.apache.org/release/accumulo-1.8.0/#testing
http://accumulo.apache.org/release/accumulo-1.8.1/#testing

On Tue, Jun 6, 2017 at 11:14 AM, Marc <[hidden email]> wrote:

> I'm not sure it would solve Bob's concern of having more "soak time," but
> we could clarify that 1.8.1 is Stable.
>
> The linux kernel makes the releases very clear:  https://www.kernel.org/
>
> Do you think that presenting 1.8.1 as the stable branch will help? I see
> the Releases dropdown shows 1.8.1 as 'Latest'. In my opinion that doesn't
> serve 1.8.1 very well.
>
> Some will believe it's too new to try regardless of nomenclature, but
> personally I see Latest and think "let someone else try it first."
>
> On Tue, Jun 6, 2017 at 12:02 PM, Mike Drob <[hidden email]> wrote:
>
>> As a specific example of folks looking at 1.7.3 as stable and seeing 1.8.x
>> as unstable, we have a current thread on the dev list -
>> https://lists.apache.org/thread.html/6e83fc644437c41ace5847d1cd5622
>> f8174f7e0f8dfd1a30a8fd7116@%3Cdev.accumulo.apache.org%3E
>>
>> Right or wrong, that's the way things are right now.
>>
>> On Mon, Jun 5, 2017 at 5:52 PM, Christopher <[hidden email]> wrote:
>>
>> > The way I think about it, the 1.x line is our LTS release, not a specific
>> > minor release within 1.x (at least, since we starting guaranteeing
>> > backwards compatibility). This is because even in LTS models like Ubuntu
>> or
>> > RHEL, new features are added if they are backwards-compatible. This is
>> why
>> > I think we're possibly not doing a good enough job at declaring that the
>> > newer minor releases in 1.x can/should be upgraded to once we think
>> they're
>> > stable. This is a bit like the RHEL model. The "LTS" release is RHEL 7,
>> and
>> > maintenance effectively stops on 7.2 once 7.3 is released, because the
>> > patch process becomes "update to 7.3". Most people wouldn't consider an
>> > upgrade from 7.2 to 7.3 a risky update, because of the delivery mechanism
>> > (patch releases... updates to specific RPMs... are delivered the same way
>> > as minor releases: yum update). So, in a sense, I think the reason we're
>> > having this discussion is because we don't have a good "delivery
>> mechanism"
>> > to ensure upgrade confidence to the next minor release. The analogy isn't
>> > perfect, but hopefully that gives a hint at how I'm thinking about "LTS".
>> > Major releases seem to be a natural demarcation point for me for the
>> "LTS"
>> > concept.
>> >
>> > What it really comes down to for me, is "what is the upgrade path?" And,
>> I
>> > think our current model of having so many, sometimes inconsistent (due to
>> > timing of releases), upgrade paths isn't very efficient, is potentially
>> > confusing, and I worry that it's inhibiting the goal that we all seem to
>> > agree needs to happen: more frequent patch releases.
>> >
>> > Currently, our de facto support mechanism is the "last 2 minor releases"
>> > (dev minus 1, dev minus 2).
>> > I opened this conversation suggesting that, perhaps, it is better to
>> switch
>> > to "last 1 minor releases (once stable)" (dev-1).
>> > A middle-ground might be: "last 1 minor release (once stable) for routine
>> > patches + last 2 minor releases for critical or on-demand patches".
>> (dev-1,
>> > dev-2*).
>> >
>> > The way that middle ground might work is: we clean up JIRA so that we
>> don't
>> > have to keep bumping issues which aren't being worked on (dev-2). Instead
>> > of starting patches at (dev-2), merging into (dev-1), and then into
>> > (dev/master), we start at (dev-1). If it's a critical issue, we'll
>> probably
>> > want to start at (dev-2). If somebody contributes specifically because
>> they
>> > need/want something fixed in (dev-2), we encourage them to do so, and
>> take
>> > the opportunity to on-board a new committer as that patch is applied and
>> > released. We won't say "no" to (dev-2) patches and releases, but we don't
>> > have to require every routine patch start that far back, either. Patches
>> > can always be backported to (dev-2) on-demand if somebody is willing to
>> > champion it.
>> >
>> >
>> > On Mon, Jun 5, 2017 at 5:43 PM Sean Busbey <[hidden email]> wrote:
>> >
>> > > We should remove the 1.6 stuff, since it went EOM back in September
>> 2016.
>> > >
>> > > FWIW, all the folks I have visibility into are running either 1.4 (I
>> > > know... :( ), 1.6, or 1.7. Granted this is biased by the fact that the
>> > > vast majority (but not all) are relying on something "Powered By"
>> > > those apache release versions and the provider of those "powered by"
>> > > bits don't offer anything based on 1.8.
>> > >
>> > > I like the idea of having a LTS branch. Something analogous to what
>> > > I've seen other communities do by designating a "current stable"
>> > > release line that's expected to keep getting updates for longer. It
>> > > makes it easy to guide most folks towards using that version.
>> > >
>> > > Another possibility is to change how we structure application of fixes
>> > > so that every developer doesn't have to deal with every active branch.
>> > > Apache Avro, for example, historically just had everyone patch to the
>> > > trunk branch and left it up to release managers to cherry pick back to
>> > > active release lines.
>> > >
>> > > On Mon, Jun 5, 2017 at 4:01 PM, Mike Walch <[hidden email]> wrote:
>> > > > My examples in my last email assume that 1.8 is the first LTS branch.
>> > I
>> > > > think this makes sense as 1.8 should be the last 1.x release.
>> > > >
>> > > > On Mon, Jun 5, 2017 at 4:52 PM Mike Walch <[hidden email]> wrote:
>> > > >
>> > > >> This debate seems to come up frequently and the viewpoints expressed
>> > > seem
>> > > >> to represent one of two groups of Accumulo users:
>> > > >>
>> > > >> 1. conservative, enterprise users that want to avoid upgrades and
>> want
>> > > >> long-term support.
>> > > >> 2. early adopters and developers that want frequent minor releases
>> as
>> > > they
>> > > >> are willing to upgrade and don't care about long-term support.
>> > > >>
>> > > >> I think our goal should be keep both groups happy as enterprise
>> users
>> > > >> typically pay the bills and early adopters/developers help test out
>> > new
>> > > >> releases and features.
>> > > >>
>> > > >> Currently, we advertise a 1.6, 1.7, and 1.8 release on our downloads
>> > > page.
>> > > >> If I was an enterprise user, I would not know which release to use
>> or
>> > > >> upgrade to.  I think we should instead identify certain minor
>> releases
>> > > as
>> > > >> long-term support releases (LTS) (like Ubuntu) and push enterprise
>> > > users to
>> > > >> use them.
>> > > >>
>> > > >> Our website and downloads push could advertise the latest release
>> and
>> > > the
>> > > >> latest LTS release.  This could allow us to minimize the number of
>> > > >> maintenance branches by only supporting the latest minor release
>> > branch
>> > > and
>> > > >> latest LTS branch.  For example, if our latest release is 2.2.0, we
>> > can
>> > > >> drop support for the 2.0 & 2.1 branches but support new bugfix
>> > releases
>> > > on
>> > > >> the 2.2 and 1.8 branches.
>> > > >>
>> > > >> If the 2.2 branch is identified as the next LTS branch, we could
>> > develop
>> > > >> an easy upgrade script for enterprise users to go directly from 1.8
>> to
>> > > 2.2
>> > > >> (skipping 2.0, 2.1).
>> > > >>
>> > > >> On Mon, Jun 5, 2017 at 3:12 PM Christopher <[hidden email]>
>> > wrote:
>> > > >>
>> > > >>> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <[hidden email]>
>> > > wrote:
>> > > >>>
>> > > >>> > On Mon, Jun 5, 2017 at 11:12 AM, Christopher <
>> [hidden email]>
>> > > >>> wrote:
>> > > >>> > > On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <
>> [hidden email]
>> > >
>> > > >>> wrote:
>> > > >>> > >
>> > > >>> > >> Many users in enterprise spaces have rules for upgrading to
>> > > >>> > >> a new maintenance release that are different from upgrading
>> to a
>> > > new
>> > > >>> > >> minor release. Those rules presume a uniform understanding of
>> > the
>> > > >>> > >> risks involved in each of those kinds of releases that I don't
>> > > think
>> > > >>> > >> exists, especially across open source projects, but
>> nonetheless
>> > > those
>> > > >>> > >> are the rules the organization is stuck with. For those users,
>> > > >>> > >> continued maintenance releases that include critical bug fixes
>> > are
>> > > >>> key
>> > > >>> > >> to allowing them to consume our releases.
>> > > >>> > >>
>> > > >>> > >>
>> > > >>> > > I agree that occurs, but I also think that such rules in
>> > > enterprises
>> > > >>> > don't
>> > > >>> > > exist in a vacuum. They exist in the context of what the
>> project
>> > > >>> itself
>> > > >>> > is
>> > > >>> > > doing. Choosing to upgrade to a new maintenance release is only
>> > an
>> > > >>> option
>> > > >>> > > when the upstream project is still producing maintenance
>> > releases.
>> > > >>> Since
>> > > >>> > > that's at the core of what this discussion is about, the
>> question
>> > > >>> becomes
>> > > >>> > > something like "If we do this, will we be encouraging
>> [enterprise
>> > > and
>> > > >>> > > other] users to use the latest minor.patch release on their
>> next
>> > > >>> upgrade
>> > > >>> > > cycle, or are we discouraging them from upgrading at all?" I
>> > don't
>> > > >>> know
>> > > >>> > the
>> > > >>> > > answer, but if it's the latter, the next question is "Can we
>> > > correct
>> > > >>> for
>> > > >>> > > any misperceived risks by better communicating what we know
>> about
>> > > >>> upgrade
>> > > >>> > > risks to newer minor versions?" I don't know the answer to that
>> > > >>> question,
>> > > >>> > > either.
>> > > >>> > >
>> > > >>> > > In my experience with my "enterprise" customers, the reluctance
>> > to
>> > > >>> > upgrade
>> > > >>> > > seems to apply equally to all versions. I recently provided
>> > > support to
>> > > >>> > > somebody still running 1.5.0, in spite of the 1.5 line being on
>> > > 1.5.4
>> > > >>> and
>> > > >>> > > *very* EOL, because of reluctance to upgrade.
>> > > >>> > >
>> > > >>> >
>> > > >>> > In my limited experience, when ASF projects don't reliably make
>> > > >>> > maintenance releases, enterprise customers turn to vendors to
>> > provide
>> > > >>> > a source of conservative updates. Phrased another way, it's a
>> thing
>> > > >>> > that I see pointed to for why a decision maker might pick a
>> vendor
>> > > >>> > "powered by" an asf project rather than asf blessed releases.
>> > > >>> >
>> > > >>> >
>> > > >>> I've seen that, too. Are you suggesting that's a problem?
>> > > >>>
>> > > >>> I'm interested in providing more frequent releases on fewer
>> > maintenance
>> > > >>> branches. But, if a vendor wants to provide an alternate upgrade
>> path
>> > > to
>> > > >>> fill a specific need for users with special requirements for
>> earlier
>> > > >>> branches, I think that's fine.
>> > > >>>
>> > > >>
>> > >
>> > >
>> > >
>> > > --
>> > > busbey
>> > >
>> >
>>



--
busbey
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Marc
Sean,
  The nomenclature doesn't imply that there are no bugs. Take for example
how open stack defines it [1]. I don't mean to imply that it's free from
bugs. We have to be clear that what we intend to be the location that is a
"safe source of fixes," while others may only get security patches

 I too saw a degradation when testing my native c++ client with 1.7. I then
saw an improvement in 1.8, but other random thrift issues. Stable needs to
be clearly defined.  I agree with you about 1.8. If we define stability to
mean "we pass these tests," then we should never have released it. Alas we
did and thus we have to give users a clear release that will be maintained
and clarify how it will be and how long it will be maintained.

My goal was not to imply 1.8 works and we should move to it, but rather
that whatever we define as stable and the primary location of bug fixes,
improvements, and security patches, is very clear to users.

[1] https://docs.openstack.org/project-team-guide/stable-branches.html

On Tue, Jun 6, 2017 at 12:39 PM, Sean Busbey <[hidden email]> wrote:

> Why do we consider 1.8.1 stable?
>
> For example, has anyone done perf comparisons between 1.7 and 1.8.z?
>
> When it came time for me to start telling folks that it was "safe" to
> upgrade to 1.7.z I ran into something like a 40-60% perf degradation
> on writes compared to 1.6 across the board. A little bit of this was
> already fixed in 1.8 at the time, but a substantial amount required a
> non-trivial refactoring because just no one had looked[1]. Even after
> all of that, I still had to caveat things because I still saw a
> ~15-30% perf drop on random writes in the presence of lots of columns.
>
> Also, attempting to check correctness via the RandomWalk test showed
> that things had just stopped working on the 1.7 release line[2].
> Reading the release notes for 1.8.z releases shows that no one has run
> it as a part of 1.8.z RC testing[3]. Does it work now?
>
> How polished are the features in 1.8.z? The work that went in to
> getting kerberos for clients in the 1.7 line was great, but still
> there were several fit-in-finish bits that came up a year and a half
> into the 1.7 branch (minor deployment snags, some docs clarifications,
> etc). Have we done a similar pass though the things we advertise in
> 1.8?
>
> I don't mean for this to come across as a lot of complaining or
> foisting work upon others. But if we're going to call something
> "stable" as a project, these are the kinds of things the downstream
> users I interact will will expect to have happened.
>
>
> [1]: https://issues.apache.org/jira/browse/ACCUMULO-4458
> [2]: https://issues.apache.org/jira/browse/ACCUMULO-4467
> [3]:
>
> http://accumulo.apache.org/release/accumulo-1.8.0/#testing
> http://accumulo.apache.org/release/accumulo-1.8.1/#testing
>
> On Tue, Jun 6, 2017 at 11:14 AM, Marc <[hidden email]> wrote:
> > I'm not sure it would solve Bob's concern of having more "soak time," but
> > we could clarify that 1.8.1 is Stable.
> >
> > The linux kernel makes the releases very clear:  https://www.kernel.org/
> >
> > Do you think that presenting 1.8.1 as the stable branch will help? I see
> > the Releases dropdown shows 1.8.1 as 'Latest'. In my opinion that doesn't
> > serve 1.8.1 very well.
> >
> > Some will believe it's too new to try regardless of nomenclature, but
> > personally I see Latest and think "let someone else try it first."
> >
> > On Tue, Jun 6, 2017 at 12:02 PM, Mike Drob <[hidden email]> wrote:
> >
> >> As a specific example of folks looking at 1.7.3 as stable and seeing
> 1.8.x
> >> as unstable, we have a current thread on the dev list -
> >> https://lists.apache.org/thread.html/6e83fc644437c41ace5847d1cd5622
> >> f8174f7e0f8dfd1a30a8fd7116@%3Cdev.accumulo.apache.org%3E
> >>
> >> Right or wrong, that's the way things are right now.
> >>
> >> On Mon, Jun 5, 2017 at 5:52 PM, Christopher <[hidden email]>
> wrote:
> >>
> >> > The way I think about it, the 1.x line is our LTS release, not a
> specific
> >> > minor release within 1.x (at least, since we starting guaranteeing
> >> > backwards compatibility). This is because even in LTS models like
> Ubuntu
> >> or
> >> > RHEL, new features are added if they are backwards-compatible. This is
> >> why
> >> > I think we're possibly not doing a good enough job at declaring that
> the
> >> > newer minor releases in 1.x can/should be upgraded to once we think
> >> they're
> >> > stable. This is a bit like the RHEL model. The "LTS" release is RHEL
> 7,
> >> and
> >> > maintenance effectively stops on 7.2 once 7.3 is released, because the
> >> > patch process becomes "update to 7.3". Most people wouldn't consider
> an
> >> > upgrade from 7.2 to 7.3 a risky update, because of the delivery
> mechanism
> >> > (patch releases... updates to specific RPMs... are delivered the same
> way
> >> > as minor releases: yum update). So, in a sense, I think the reason
> we're
> >> > having this discussion is because we don't have a good "delivery
> >> mechanism"
> >> > to ensure upgrade confidence to the next minor release. The analogy
> isn't
> >> > perfect, but hopefully that gives a hint at how I'm thinking about
> "LTS".
> >> > Major releases seem to be a natural demarcation point for me for the
> >> "LTS"
> >> > concept.
> >> >
> >> > What it really comes down to for me, is "what is the upgrade path?"
> And,
> >> I
> >> > think our current model of having so many, sometimes inconsistent
> (due to
> >> > timing of releases), upgrade paths isn't very efficient, is
> potentially
> >> > confusing, and I worry that it's inhibiting the goal that we all seem
> to
> >> > agree needs to happen: more frequent patch releases.
> >> >
> >> > Currently, our de facto support mechanism is the "last 2 minor
> releases"
> >> > (dev minus 1, dev minus 2).
> >> > I opened this conversation suggesting that, perhaps, it is better to
> >> switch
> >> > to "last 1 minor releases (once stable)" (dev-1).
> >> > A middle-ground might be: "last 1 minor release (once stable) for
> routine
> >> > patches + last 2 minor releases for critical or on-demand patches".
> >> (dev-1,
> >> > dev-2*).
> >> >
> >> > The way that middle ground might work is: we clean up JIRA so that we
> >> don't
> >> > have to keep bumping issues which aren't being worked on (dev-2).
> Instead
> >> > of starting patches at (dev-2), merging into (dev-1), and then into
> >> > (dev/master), we start at (dev-1). If it's a critical issue, we'll
> >> probably
> >> > want to start at (dev-2). If somebody contributes specifically because
> >> they
> >> > need/want something fixed in (dev-2), we encourage them to do so, and
> >> take
> >> > the opportunity to on-board a new committer as that patch is applied
> and
> >> > released. We won't say "no" to (dev-2) patches and releases, but we
> don't
> >> > have to require every routine patch start that far back, either.
> Patches
> >> > can always be backported to (dev-2) on-demand if somebody is willing
> to
> >> > champion it.
> >> >
> >> >
> >> > On Mon, Jun 5, 2017 at 5:43 PM Sean Busbey <[hidden email]>
> wrote:
> >> >
> >> > > We should remove the 1.6 stuff, since it went EOM back in September
> >> 2016.
> >> > >
> >> > > FWIW, all the folks I have visibility into are running either 1.4 (I
> >> > > know... :( ), 1.6, or 1.7. Granted this is biased by the fact that
> the
> >> > > vast majority (but not all) are relying on something "Powered By"
> >> > > those apache release versions and the provider of those "powered by"
> >> > > bits don't offer anything based on 1.8.
> >> > >
> >> > > I like the idea of having a LTS branch. Something analogous to what
> >> > > I've seen other communities do by designating a "current stable"
> >> > > release line that's expected to keep getting updates for longer. It
> >> > > makes it easy to guide most folks towards using that version.
> >> > >
> >> > > Another possibility is to change how we structure application of
> fixes
> >> > > so that every developer doesn't have to deal with every active
> branch.
> >> > > Apache Avro, for example, historically just had everyone patch to
> the
> >> > > trunk branch and left it up to release managers to cherry pick back
> to
> >> > > active release lines.
> >> > >
> >> > > On Mon, Jun 5, 2017 at 4:01 PM, Mike Walch <[hidden email]>
> wrote:
> >> > > > My examples in my last email assume that 1.8 is the first LTS
> branch.
> >> > I
> >> > > > think this makes sense as 1.8 should be the last 1.x release.
> >> > > >
> >> > > > On Mon, Jun 5, 2017 at 4:52 PM Mike Walch <[hidden email]>
> wrote:
> >> > > >
> >> > > >> This debate seems to come up frequently and the viewpoints
> expressed
> >> > > seem
> >> > > >> to represent one of two groups of Accumulo users:
> >> > > >>
> >> > > >> 1. conservative, enterprise users that want to avoid upgrades and
> >> want
> >> > > >> long-term support.
> >> > > >> 2. early adopters and developers that want frequent minor
> releases
> >> as
> >> > > they
> >> > > >> are willing to upgrade and don't care about long-term support.
> >> > > >>
> >> > > >> I think our goal should be keep both groups happy as enterprise
> >> users
> >> > > >> typically pay the bills and early adopters/developers help test
> out
> >> > new
> >> > > >> releases and features.
> >> > > >>
> >> > > >> Currently, we advertise a 1.6, 1.7, and 1.8 release on our
> downloads
> >> > > page.
> >> > > >> If I was an enterprise user, I would not know which release to
> use
> >> or
> >> > > >> upgrade to.  I think we should instead identify certain minor
> >> releases
> >> > > as
> >> > > >> long-term support releases (LTS) (like Ubuntu) and push
> enterprise
> >> > > users to
> >> > > >> use them.
> >> > > >>
> >> > > >> Our website and downloads push could advertise the latest release
> >> and
> >> > > the
> >> > > >> latest LTS release.  This could allow us to minimize the number
> of
> >> > > >> maintenance branches by only supporting the latest minor release
> >> > branch
> >> > > and
> >> > > >> latest LTS branch.  For example, if our latest release is 2.2.0,
> we
> >> > can
> >> > > >> drop support for the 2.0 & 2.1 branches but support new bugfix
> >> > releases
> >> > > on
> >> > > >> the 2.2 and 1.8 branches.
> >> > > >>
> >> > > >> If the 2.2 branch is identified as the next LTS branch, we could
> >> > develop
> >> > > >> an easy upgrade script for enterprise users to go directly from
> 1.8
> >> to
> >> > > 2.2
> >> > > >> (skipping 2.0, 2.1).
> >> > > >>
> >> > > >> On Mon, Jun 5, 2017 at 3:12 PM Christopher <[hidden email]>
> >> > wrote:
> >> > > >>
> >> > > >>> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <[hidden email]
> >
> >> > > wrote:
> >> > > >>>
> >> > > >>> > On Mon, Jun 5, 2017 at 11:12 AM, Christopher <
> >> [hidden email]>
> >> > > >>> wrote:
> >> > > >>> > > On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <
> >> [hidden email]
> >> > >
> >> > > >>> wrote:
> >> > > >>> > >
> >> > > >>> > >> Many users in enterprise spaces have rules for upgrading to
> >> > > >>> > >> a new maintenance release that are different from upgrading
> >> to a
> >> > > new
> >> > > >>> > >> minor release. Those rules presume a uniform understanding
> of
> >> > the
> >> > > >>> > >> risks involved in each of those kinds of releases that I
> don't
> >> > > think
> >> > > >>> > >> exists, especially across open source projects, but
> >> nonetheless
> >> > > those
> >> > > >>> > >> are the rules the organization is stuck with. For those
> users,
> >> > > >>> > >> continued maintenance releases that include critical bug
> fixes
> >> > are
> >> > > >>> key
> >> > > >>> > >> to allowing them to consume our releases.
> >> > > >>> > >>
> >> > > >>> > >>
> >> > > >>> > > I agree that occurs, but I also think that such rules in
> >> > > enterprises
> >> > > >>> > don't
> >> > > >>> > > exist in a vacuum. They exist in the context of what the
> >> project
> >> > > >>> itself
> >> > > >>> > is
> >> > > >>> > > doing. Choosing to upgrade to a new maintenance release is
> only
> >> > an
> >> > > >>> option
> >> > > >>> > > when the upstream project is still producing maintenance
> >> > releases.
> >> > > >>> Since
> >> > > >>> > > that's at the core of what this discussion is about, the
> >> question
> >> > > >>> becomes
> >> > > >>> > > something like "If we do this, will we be encouraging
> >> [enterprise
> >> > > and
> >> > > >>> > > other] users to use the latest minor.patch release on their
> >> next
> >> > > >>> upgrade
> >> > > >>> > > cycle, or are we discouraging them from upgrading at all?" I
> >> > don't
> >> > > >>> know
> >> > > >>> > the
> >> > > >>> > > answer, but if it's the latter, the next question is "Can we
> >> > > correct
> >> > > >>> for
> >> > > >>> > > any misperceived risks by better communicating what we know
> >> about
> >> > > >>> upgrade
> >> > > >>> > > risks to newer minor versions?" I don't know the answer to
> that
> >> > > >>> question,
> >> > > >>> > > either.
> >> > > >>> > >
> >> > > >>> > > In my experience with my "enterprise" customers, the
> reluctance
> >> > to
> >> > > >>> > upgrade
> >> > > >>> > > seems to apply equally to all versions. I recently provided
> >> > > support to
> >> > > >>> > > somebody still running 1.5.0, in spite of the 1.5 line
> being on
> >> > > 1.5.4
> >> > > >>> and
> >> > > >>> > > *very* EOL, because of reluctance to upgrade.
> >> > > >>> > >
> >> > > >>> >
> >> > > >>> > In my limited experience, when ASF projects don't reliably
> make
> >> > > >>> > maintenance releases, enterprise customers turn to vendors to
> >> > provide
> >> > > >>> > a source of conservative updates. Phrased another way, it's a
> >> thing
> >> > > >>> > that I see pointed to for why a decision maker might pick a
> >> vendor
> >> > > >>> > "powered by" an asf project rather than asf blessed releases.
> >> > > >>> >
> >> > > >>> >
> >> > > >>> I've seen that, too. Are you suggesting that's a problem?
> >> > > >>>
> >> > > >>> I'm interested in providing more frequent releases on fewer
> >> > maintenance
> >> > > >>> branches. But, if a vendor wants to provide an alternate upgrade
> >> path
> >> > > to
> >> > > >>> fill a specific need for users with special requirements for
> >> earlier
> >> > > >>> branches, I think that's fine.
> >> > > >>>
> >> > > >>
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > busbey
> >> > >
> >> >
> >>
>
>
>
> --
> busbey
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Josh Elser
In reply to this post by Sean Busbey
On 6/6/17 12:39 PM, Sean Busbey wrote:
> For example, has anyone done perf comparisons between 1.7 and 1.8.z?
>
> When it came time for me to start telling folks that it was "safe" to
> upgrade to 1.7.z I ran into something like a 40-60% perf degradation
> on writes compared to 1.6 across the board. A little bit of this was
> already fixed in 1.8 at the time, but a substantial amount required a
> non-trivial refactoring because just no one had looked[1]. Even after
> all of that, I still had to caveat things because I still saw a
> ~15-30% perf drop on random writes in the presence of lots of columns.

At a risk of de-railing otherwise good discussion on releases: do you
recall if you had accounted for the following, Sean? (notably, the last
code snippet)

https://accumulo.apache.org/blog/2016/11/02/durability-performance.html
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Sean Busbey
In reply to this post by Marc
I definitely don't mean to say we have to claim a branch is bug-free
to be the stable branch. These kinds of tests are just the things we
used to do on every release that we at some point relaxed to only
"major" releases in an effort to increase our release cadence. Then we
adopted semver and expressly started making 1.y releases "minor",
which meant a lot of this testing just hasn't happened in a long time.
That naturally means some stuff is going to slip through the cracks
and downstream folks rightfully notice when we lapse.

I'm definitely on board with the idea that we should be providing more
sign posts to simplify the easy path for folks that want to get
started. I just think that pointer should probably currently point at
branch-1.7 and should only be updated when we can show that we've done
enough due diligence that the majority of downstream folks can expect
an upgrade that doesn't come with surprises.



On Tue, Jun 6, 2017 at 11:51 AM, Marc <[hidden email]> wrote:

> Sean,
>   The nomenclature doesn't imply that there are no bugs. Take for example
> how open stack defines it [1]. I don't mean to imply that it's free from
> bugs. We have to be clear that what we intend to be the location that is a
> "safe source of fixes," while others may only get security patches
>
>  I too saw a degradation when testing my native c++ client with 1.7. I then
> saw an improvement in 1.8, but other random thrift issues. Stable needs to
> be clearly defined.  I agree with you about 1.8. If we define stability to
> mean "we pass these tests," then we should never have released it. Alas we
> did and thus we have to give users a clear release that will be maintained
> and clarify how it will be and how long it will be maintained.
>
> My goal was not to imply 1.8 works and we should move to it, but rather
> that whatever we define as stable and the primary location of bug fixes,
> improvements, and security patches, is very clear to users.
>
> [1] https://docs.openstack.org/project-team-guide/stable-branches.html
>
> On Tue, Jun 6, 2017 at 12:39 PM, Sean Busbey <[hidden email]> wrote:
>
>> Why do we consider 1.8.1 stable?
>>
>> For example, has anyone done perf comparisons between 1.7 and 1.8.z?
>>
>> When it came time for me to start telling folks that it was "safe" to
>> upgrade to 1.7.z I ran into something like a 40-60% perf degradation
>> on writes compared to 1.6 across the board. A little bit of this was
>> already fixed in 1.8 at the time, but a substantial amount required a
>> non-trivial refactoring because just no one had looked[1]. Even after
>> all of that, I still had to caveat things because I still saw a
>> ~15-30% perf drop on random writes in the presence of lots of columns.
>>
>> Also, attempting to check correctness via the RandomWalk test showed
>> that things had just stopped working on the 1.7 release line[2].
>> Reading the release notes for 1.8.z releases shows that no one has run
>> it as a part of 1.8.z RC testing[3]. Does it work now?
>>
>> How polished are the features in 1.8.z? The work that went in to
>> getting kerberos for clients in the 1.7 line was great, but still
>> there were several fit-in-finish bits that came up a year and a half
>> into the 1.7 branch (minor deployment snags, some docs clarifications,
>> etc). Have we done a similar pass though the things we advertise in
>> 1.8?
>>
>> I don't mean for this to come across as a lot of complaining or
>> foisting work upon others. But if we're going to call something
>> "stable" as a project, these are the kinds of things the downstream
>> users I interact will will expect to have happened.
>>
>>
>> [1]: https://issues.apache.org/jira/browse/ACCUMULO-4458
>> [2]: https://issues.apache.org/jira/browse/ACCUMULO-4467
>> [3]:
>>
>> http://accumulo.apache.org/release/accumulo-1.8.0/#testing
>> http://accumulo.apache.org/release/accumulo-1.8.1/#testing
>>
>> On Tue, Jun 6, 2017 at 11:14 AM, Marc <[hidden email]> wrote:
>> > I'm not sure it would solve Bob's concern of having more "soak time," but
>> > we could clarify that 1.8.1 is Stable.
>> >
>> > The linux kernel makes the releases very clear:  https://www.kernel.org/
>> >
>> > Do you think that presenting 1.8.1 as the stable branch will help? I see
>> > the Releases dropdown shows 1.8.1 as 'Latest'. In my opinion that doesn't
>> > serve 1.8.1 very well.
>> >
>> > Some will believe it's too new to try regardless of nomenclature, but
>> > personally I see Latest and think "let someone else try it first."
>> >
>> > On Tue, Jun 6, 2017 at 12:02 PM, Mike Drob <[hidden email]> wrote:
>> >
>> >> As a specific example of folks looking at 1.7.3 as stable and seeing
>> 1.8.x
>> >> as unstable, we have a current thread on the dev list -
>> >> https://lists.apache.org/thread.html/6e83fc644437c41ace5847d1cd5622
>> >> f8174f7e0f8dfd1a30a8fd7116@%3Cdev.accumulo.apache.org%3E
>> >>
>> >> Right or wrong, that's the way things are right now.
>> >>
>> >> On Mon, Jun 5, 2017 at 5:52 PM, Christopher <[hidden email]>
>> wrote:
>> >>
>> >> > The way I think about it, the 1.x line is our LTS release, not a
>> specific
>> >> > minor release within 1.x (at least, since we starting guaranteeing
>> >> > backwards compatibility). This is because even in LTS models like
>> Ubuntu
>> >> or
>> >> > RHEL, new features are added if they are backwards-compatible. This is
>> >> why
>> >> > I think we're possibly not doing a good enough job at declaring that
>> the
>> >> > newer minor releases in 1.x can/should be upgraded to once we think
>> >> they're
>> >> > stable. This is a bit like the RHEL model. The "LTS" release is RHEL
>> 7,
>> >> and
>> >> > maintenance effectively stops on 7.2 once 7.3 is released, because the
>> >> > patch process becomes "update to 7.3". Most people wouldn't consider
>> an
>> >> > upgrade from 7.2 to 7.3 a risky update, because of the delivery
>> mechanism
>> >> > (patch releases... updates to specific RPMs... are delivered the same
>> way
>> >> > as minor releases: yum update). So, in a sense, I think the reason
>> we're
>> >> > having this discussion is because we don't have a good "delivery
>> >> mechanism"
>> >> > to ensure upgrade confidence to the next minor release. The analogy
>> isn't
>> >> > perfect, but hopefully that gives a hint at how I'm thinking about
>> "LTS".
>> >> > Major releases seem to be a natural demarcation point for me for the
>> >> "LTS"
>> >> > concept.
>> >> >
>> >> > What it really comes down to for me, is "what is the upgrade path?"
>> And,
>> >> I
>> >> > think our current model of having so many, sometimes inconsistent
>> (due to
>> >> > timing of releases), upgrade paths isn't very efficient, is
>> potentially
>> >> > confusing, and I worry that it's inhibiting the goal that we all seem
>> to
>> >> > agree needs to happen: more frequent patch releases.
>> >> >
>> >> > Currently, our de facto support mechanism is the "last 2 minor
>> releases"
>> >> > (dev minus 1, dev minus 2).
>> >> > I opened this conversation suggesting that, perhaps, it is better to
>> >> switch
>> >> > to "last 1 minor releases (once stable)" (dev-1).
>> >> > A middle-ground might be: "last 1 minor release (once stable) for
>> routine
>> >> > patches + last 2 minor releases for critical or on-demand patches".
>> >> (dev-1,
>> >> > dev-2*).
>> >> >
>> >> > The way that middle ground might work is: we clean up JIRA so that we
>> >> don't
>> >> > have to keep bumping issues which aren't being worked on (dev-2).
>> Instead
>> >> > of starting patches at (dev-2), merging into (dev-1), and then into
>> >> > (dev/master), we start at (dev-1). If it's a critical issue, we'll
>> >> probably
>> >> > want to start at (dev-2). If somebody contributes specifically because
>> >> they
>> >> > need/want something fixed in (dev-2), we encourage them to do so, and
>> >> take
>> >> > the opportunity to on-board a new committer as that patch is applied
>> and
>> >> > released. We won't say "no" to (dev-2) patches and releases, but we
>> don't
>> >> > have to require every routine patch start that far back, either.
>> Patches
>> >> > can always be backported to (dev-2) on-demand if somebody is willing
>> to
>> >> > champion it.
>> >> >
>> >> >
>> >> > On Mon, Jun 5, 2017 at 5:43 PM Sean Busbey <[hidden email]>
>> wrote:
>> >> >
>> >> > > We should remove the 1.6 stuff, since it went EOM back in September
>> >> 2016.
>> >> > >
>> >> > > FWIW, all the folks I have visibility into are running either 1.4 (I
>> >> > > know... :( ), 1.6, or 1.7. Granted this is biased by the fact that
>> the
>> >> > > vast majority (but not all) are relying on something "Powered By"
>> >> > > those apache release versions and the provider of those "powered by"
>> >> > > bits don't offer anything based on 1.8.
>> >> > >
>> >> > > I like the idea of having a LTS branch. Something analogous to what
>> >> > > I've seen other communities do by designating a "current stable"
>> >> > > release line that's expected to keep getting updates for longer. It
>> >> > > makes it easy to guide most folks towards using that version.
>> >> > >
>> >> > > Another possibility is to change how we structure application of
>> fixes
>> >> > > so that every developer doesn't have to deal with every active
>> branch.
>> >> > > Apache Avro, for example, historically just had everyone patch to
>> the
>> >> > > trunk branch and left it up to release managers to cherry pick back
>> to
>> >> > > active release lines.
>> >> > >
>> >> > > On Mon, Jun 5, 2017 at 4:01 PM, Mike Walch <[hidden email]>
>> wrote:
>> >> > > > My examples in my last email assume that 1.8 is the first LTS
>> branch.
>> >> > I
>> >> > > > think this makes sense as 1.8 should be the last 1.x release.
>> >> > > >
>> >> > > > On Mon, Jun 5, 2017 at 4:52 PM Mike Walch <[hidden email]>
>> wrote:
>> >> > > >
>> >> > > >> This debate seems to come up frequently and the viewpoints
>> expressed
>> >> > > seem
>> >> > > >> to represent one of two groups of Accumulo users:
>> >> > > >>
>> >> > > >> 1. conservative, enterprise users that want to avoid upgrades and
>> >> want
>> >> > > >> long-term support.
>> >> > > >> 2. early adopters and developers that want frequent minor
>> releases
>> >> as
>> >> > > they
>> >> > > >> are willing to upgrade and don't care about long-term support.
>> >> > > >>
>> >> > > >> I think our goal should be keep both groups happy as enterprise
>> >> users
>> >> > > >> typically pay the bills and early adopters/developers help test
>> out
>> >> > new
>> >> > > >> releases and features.
>> >> > > >>
>> >> > > >> Currently, we advertise a 1.6, 1.7, and 1.8 release on our
>> downloads
>> >> > > page.
>> >> > > >> If I was an enterprise user, I would not know which release to
>> use
>> >> or
>> >> > > >> upgrade to.  I think we should instead identify certain minor
>> >> releases
>> >> > > as
>> >> > > >> long-term support releases (LTS) (like Ubuntu) and push
>> enterprise
>> >> > > users to
>> >> > > >> use them.
>> >> > > >>
>> >> > > >> Our website and downloads push could advertise the latest release
>> >> and
>> >> > > the
>> >> > > >> latest LTS release.  This could allow us to minimize the number
>> of
>> >> > > >> maintenance branches by only supporting the latest minor release
>> >> > branch
>> >> > > and
>> >> > > >> latest LTS branch.  For example, if our latest release is 2.2.0,
>> we
>> >> > can
>> >> > > >> drop support for the 2.0 & 2.1 branches but support new bugfix
>> >> > releases
>> >> > > on
>> >> > > >> the 2.2 and 1.8 branches.
>> >> > > >>
>> >> > > >> If the 2.2 branch is identified as the next LTS branch, we could
>> >> > develop
>> >> > > >> an easy upgrade script for enterprise users to go directly from
>> 1.8
>> >> to
>> >> > > 2.2
>> >> > > >> (skipping 2.0, 2.1).
>> >> > > >>
>> >> > > >> On Mon, Jun 5, 2017 at 3:12 PM Christopher <[hidden email]>
>> >> > wrote:
>> >> > > >>
>> >> > > >>> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <[hidden email]
>> >
>> >> > > wrote:
>> >> > > >>>
>> >> > > >>> > On Mon, Jun 5, 2017 at 11:12 AM, Christopher <
>> >> [hidden email]>
>> >> > > >>> wrote:
>> >> > > >>> > > On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <
>> >> [hidden email]
>> >> > >
>> >> > > >>> wrote:
>> >> > > >>> > >
>> >> > > >>> > >> Many users in enterprise spaces have rules for upgrading to
>> >> > > >>> > >> a new maintenance release that are different from upgrading
>> >> to a
>> >> > > new
>> >> > > >>> > >> minor release. Those rules presume a uniform understanding
>> of
>> >> > the
>> >> > > >>> > >> risks involved in each of those kinds of releases that I
>> don't
>> >> > > think
>> >> > > >>> > >> exists, especially across open source projects, but
>> >> nonetheless
>> >> > > those
>> >> > > >>> > >> are the rules the organization is stuck with. For those
>> users,
>> >> > > >>> > >> continued maintenance releases that include critical bug
>> fixes
>> >> > are
>> >> > > >>> key
>> >> > > >>> > >> to allowing them to consume our releases.
>> >> > > >>> > >>
>> >> > > >>> > >>
>> >> > > >>> > > I agree that occurs, but I also think that such rules in
>> >> > > enterprises
>> >> > > >>> > don't
>> >> > > >>> > > exist in a vacuum. They exist in the context of what the
>> >> project
>> >> > > >>> itself
>> >> > > >>> > is
>> >> > > >>> > > doing. Choosing to upgrade to a new maintenance release is
>> only
>> >> > an
>> >> > > >>> option
>> >> > > >>> > > when the upstream project is still producing maintenance
>> >> > releases.
>> >> > > >>> Since
>> >> > > >>> > > that's at the core of what this discussion is about, the
>> >> question
>> >> > > >>> becomes
>> >> > > >>> > > something like "If we do this, will we be encouraging
>> >> [enterprise
>> >> > > and
>> >> > > >>> > > other] users to use the latest minor.patch release on their
>> >> next
>> >> > > >>> upgrade
>> >> > > >>> > > cycle, or are we discouraging them from upgrading at all?" I
>> >> > don't
>> >> > > >>> know
>> >> > > >>> > the
>> >> > > >>> > > answer, but if it's the latter, the next question is "Can we
>> >> > > correct
>> >> > > >>> for
>> >> > > >>> > > any misperceived risks by better communicating what we know
>> >> about
>> >> > > >>> upgrade
>> >> > > >>> > > risks to newer minor versions?" I don't know the answer to
>> that
>> >> > > >>> question,
>> >> > > >>> > > either.
>> >> > > >>> > >
>> >> > > >>> > > In my experience with my "enterprise" customers, the
>> reluctance
>> >> > to
>> >> > > >>> > upgrade
>> >> > > >>> > > seems to apply equally to all versions. I recently provided
>> >> > > support to
>> >> > > >>> > > somebody still running 1.5.0, in spite of the 1.5 line
>> being on
>> >> > > 1.5.4
>> >> > > >>> and
>> >> > > >>> > > *very* EOL, because of reluctance to upgrade.
>> >> > > >>> > >
>> >> > > >>> >
>> >> > > >>> > In my limited experience, when ASF projects don't reliably
>> make
>> >> > > >>> > maintenance releases, enterprise customers turn to vendors to
>> >> > provide
>> >> > > >>> > a source of conservative updates. Phrased another way, it's a
>> >> thing
>> >> > > >>> > that I see pointed to for why a decision maker might pick a
>> >> vendor
>> >> > > >>> > "powered by" an asf project rather than asf blessed releases.
>> >> > > >>> >
>> >> > > >>> >
>> >> > > >>> I've seen that, too. Are you suggesting that's a problem?
>> >> > > >>>
>> >> > > >>> I'm interested in providing more frequent releases on fewer
>> >> > maintenance
>> >> > > >>> branches. But, if a vendor wants to provide an alternate upgrade
>> >> path
>> >> > > to
>> >> > > >>> fill a specific need for users with special requirements for
>> >> earlier
>> >> > > >>> branches, I think that's fine.
>> >> > > >>>
>> >> > > >>
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > busbey
>> >> > >
>> >> >
>> >>
>>
>>
>>
>> --
>> busbey
>>



--
busbey
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Question about 1.7 bugfix releases

Sean Busbey
In reply to this post by Josh Elser
On Tue, Jun 6, 2017 at 12:07 PM, Josh Elser <[hidden email]> wrote:

> On 6/6/17 12:39 PM, Sean Busbey wrote:
>>
>> For example, has anyone done perf comparisons between 1.7 and 1.8.z?
>>
>> When it came time for me to start telling folks that it was "safe" to
>> upgrade to 1.7.z I ran into something like a 40-60% perf degradation
>> on writes compared to 1.6 across the board. A little bit of this was
>> already fixed in 1.8 at the time, but a substantial amount required a
>> non-trivial refactoring because just no one had looked[1]. Even after
>> all of that, I still had to caveat things because I still saw a
>> ~15-30% perf drop on random writes in the presence of lots of columns.
>
>
> At a risk of de-railing otherwise good discussion on releases: do you recall
> if you had accounted for the following, Sean? (notably, the last code
> snippet)
>
> https://accumulo.apache.org/blog/2016/11/02/durability-performance.html

I know that "set durability to flush and not sync" was one of the
parameters for the comparison, but I don't remember what was done
specifically during the testing back in September, tbh.

I can probably dig it out if you'd like; I think we were pretty good
at keeping notes. Probably something for a different thread?

--
busbey
12