". 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 <bus...@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 <phroc...@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 <bus...@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 <phroc...@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 <md...@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 <ctubb...@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 <bus...@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 <mwa...@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 <mwa...@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 < > ctubb...@apache.org> > >> >> > wrote: > >> >> > > >> > >> >> > > >>> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey < > bus...@cloudera.com > >> > > >> >> > > wrote: > >> >> > > >>> > >> >> > > >>> > On Mon, Jun 5, 2017 at 11:12 AM, Christopher < > >> >> ctubb...@apache.org> > >> >> > > >>> wrote: > >> >> > > >>> > > On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey < > >> >> bus...@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 >
