accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc P." <marc.par...@gmail.com>
Subject Re: [DISCUSS] Question about 1.7 bugfix releases
Date Tue, 06 Jun 2017 18:19:24 GMT
". 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."

+1

On Tue, Jun 6, 2017 at 2:10 PM, Sean Busbey <busbey@cloudera.com> wrote:

> 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 <phrocker@apache.org> 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 <busbey@cloudera.com>
> 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 <phrocker@apache.org> 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 <mdrob@apache.org> 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 <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
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> >> --
> >> busbey
> >>
>
>
>
> --
> busbey
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message