Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
Sender: mdrob@cloudera.com
In-Reply-To: <CAL5zq9aVTGWjVjAPT+LiBX+CZsyWYEPaL8W+R5L8B2fEBSDp8Q@mail.gmail.com>
References: <CAL5zq9bZgKVOaPu_OdVZ0mF4nQ7t9uEvjsV_nzJvwsqqUqeMvw@mail.gmail.com>
 <30741de9-e412-edda-e1b1-713cf54fc669@apache.org> <CAL5zq9Yykuha4CayHw6urTOu6RTrZk3b=Ppa=wNsmFn9fA-F+A@mail.gmail.com>
 <CAGHyZ6Jz4WMPjcC6sWW=OzDwxVwFAbxnqsJTbwC22x60EMN5RQ@mail.gmail.com>
 <CAL5zq9an2Ns1aX9i92A=wcSMoadJajgex1ZkmtqYTb3-Mc_DLw@mail.gmail.com>
 <CAGHyZ6+eKtCatBCqWJRR4DwCdZXUUi18KwEpwr9YbakLaysivA@mail.gmail.com>
 <CAL5zq9Yqg7sHC0hQTTFvWmyjw1jOyEoDQkcCOgpVP7gVtvhPRg@mail.gmail.com>
 <CAL4xCsn13R18qurFsOw8dTXsPp6tYxifg4JcdG10fxvRWUmHLA@mail.gmail.com>
 <CAL4xCsnJGKj1MT+LyOpL6nC04_ig32tt6meu3zjSEGktY-Yn8Q@mail.gmail.com>
 <CAGHyZ6+SFweMe=45XfshcCQBaBsbC6QhM2nspk7sH3+4hOt0CQ@mail.gmail.com> <CAL5zq9aVTGWjVjAPT+LiBX+CZsyWYEPaL8W+R5L8B2fEBSDp8Q@mail.gmail.com>
From: Mike Drob <mdrob@apache.org>
Date: Tue, 6 Jun 2017 11:02:38 -0500
Message-ID: <CAFAMeYKXZFDfzb9Fz568z9KL92J3juCmuV6n=aMspkugQvPx4Q@mail.gmail.com>
Subject: Re: [DISCUSS] Question about 1.7 bugfix releases
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary="001a11479acedf19bf05514cc017"
archived-at: Tue, 06 Jun 2017 16:03:14 -0000

--001a11479acedf19bf05514cc017
Content-Type: text/plain; charset="UTF-8"

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 <ctubbsii@apache.org> 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 <busbey@cloudera.com> 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 <mwalch@apache.org> 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 <mwalch@apache.org> 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 <ctubbsii@apache.org>
> wrote:
> > >>
> > >>> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <busbey@cloudera.com>
> > wrote:
> > >>>
> > >>> > On Mon, Jun 5, 2017 at 11:12 AM, Christopher <ctubbsii@apache.org>
> > >>> wrote:
> > >>> > > On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <busbey@cloudera.com
> >
> > >>> 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
> >
>

--001a11479acedf19bf05514cc017--