accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: [DISCUSS] Question about 1.7 bugfix releases
Date Tue, 06 Jun 2017 18:10:12 GMT
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
View raw message