Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: softfail (nike.apache.org: transitioning domain of
 wilhelm.von.cloud@accumulo.net does not designate 209.85.213.48 as permitted
 sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAFAMeYLP=s_Rf1cayto5gOs2iUhJ6DDxEMJ9Fj4=iii7USti8g@mail.gmail.com>
References: 
 <CAL5zq9aPieiDH+EkYLpjAu_RYRjAJ8n_ziH6jhzQvNE8XyNVAQ@mail.gmail.com>
	<CADczPYTr_aN06tDhpQdctA7agpPD4_akAn6QpQxgiNyOrxGMGw@mail.gmail.com>
	<CAGHyZ6Lj=2qjk-9JB9ZAMmnWohfHm-=6R=pgJd5BymG_NTWMDg@mail.gmail.com>
	<CAD-fFU+Xjx2R4GFDB3MxHEfh1LZ1qvzqxjXx0H30J7TqSsN+bQ@mail.gmail.com>
	<CAL5zq9aEqGDQxqUpu+EkJT=A-+K+BJShLBpv2uMqnPtBpS1NMA@mail.gmail.com>
	<01e601cf4f90$67bfc620$373f5260$@comcast.net>
	<1777229427.13692180.1396626525860.JavaMail.root@comcast.net>
	<CAL5zq9aXHBifwVBtdq+opX364jtQfRs43+anyXg3FX8R7fpLmw@mail.gmail.com>
	<CAGHyZ6K0tE1NhwtF-mtx8R7L3=3XhrrXHaMLXs7vV2viXDjqeA@mail.gmail.com>
	<CAFAMeYLP=s_Rf1cayto5gOs2iUhJ6DDxEMJ9Fj4=iii7USti8g@mail.gmail.com>
Date: Mon, 7 Apr 2014 09:26:21 -0400
Message-ID: 
 <CAMz+Duv8vm5KWa-VYwN6Pdjry8_mg+NXB4n06Jkz59B1XFchog@mail.gmail.com>
Subject: Re: [DISCUSS] Bugs-only strictness for bugfix releases
From: William Slacum <wilhelm.von.cloud@accumulo.net>
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=089e013cc12a368f0204f673d0f7

--089e013cc12a368f0204f673d0f7
Content-Type: text/plain; charset=ISO-8859-1

A bug would be something that's an actual issue outside of the expected
behavior of the program-- for instance, if we're getting a
NullPointerException while running a scan of a table that worked in a
previous state of the source code.

An improvement would be something that makes us better off, but doesn't
address any behavioral issues. I would say something like resolving
compiler warnings or your ticket regarding the use of try-with-resources.

On Mon, Apr 7, 2014 at 8:45 AM, Mike Drob <madrob@cloudera.com> wrote:

> Christopher,
>
> Can you provide a delineation between bug fix and improvement? I've noticed
> that you recategorized several issues, including ACCUMULO-2638 and
> ACCUMULO-2639 and was wondering what your criteria was for such.
>
> Is a bug-fix only something that has been reported by a user?
>
> Mike
>
>
> On Fri, Apr 4, 2014 at 4:53 PM, Sean Busbey <busbey@cloudera.com> wrote:
>
> > None of our previous 1.x releases met semver's requirements for a minor
> > version, so I don't think we need to worry about adopting that approach
> as
> > a part of the 1.6.0 release cycle.
> >
> > There are a ton of reasons I want  a 2.0.0. Given the significance of
> that
> > change I think we should have a discussion about reqs.
> >
> > It's out of scope for this thread though.
> >
> >
> > On Fri, Apr 4, 2014 at 6:46 PM, Christopher <ctubbsii@apache.org> wrote:
> >
> > > It's probably true that 1.6.0 currently would not meet semver's
> > > requirements for minor release compatibility, but something like this
> > > I think should probably change at the beginning of a dev cycle, not at
> > > the end. It seems to me that 1.7.0 would be the time to apply this,
> > > considering it 1) has a different minimum JDK version, and 2) is
> > > expected to contain a drastically improved client API module, where we
> > > could actually apply maven plugins to ensure public API versioning
> > > compliance naturally.
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> > >
> > > On Fri, Apr 4, 2014 at 11:48 AM,  <dlmarion@comcast.net> wrote:
> > > > I don't know the specifics of the api changes in 1.6.0. But I would
> be
> > > curious, if we applied the rules of something like semver, if the
> version
> > > of code in the 1.6.0 branch is not consistent with the 1.6.0 version
> > > number, but is maybe a 2.0.0.
> > > >
> > > > - Dave
> > > >
> > > > ----- Original Message -----
> > > >
> > > > From: dlmarion@comcast.net
> > > > To: dev@accumulo.apache.org
> > > > Sent: Thursday, April 3, 2014 6:59:44 PM
> > > > Subject: RE: [DISCUSS] Bugs-only strictness for bugfix releases
> > > >
> > > >
> > > > I like the idea of what semver defines (and provides in maven
> > plugins). I
> > > > don't think we are following this methodology today. I think people
> > have
> > > a
> > > > tendency to want to backport or add features to patch releases
> because
> > of
> > > > the long running release cycles (I know I have). If we could get the
> > > > testing/release cycle to be faster, then we could put out more minor
> > and
> > > > patch releases and not have long running releases. The other problem
> is
> > > > users that are stuck on a particular version. They want the patches,
> > but
> > > not
> > > > the api changes. If we could tell our consumers that 1.7 will be
> client
> > > api
> > > > compatible with 1.6, then users will likely upgrade faster and we
> will
> > > have
> > > > less pressure to backport features to a minor/patch release.
> > > >
> > > > +1 to the main idea of this thread, but I think "bug only" strictness
> > for
> > > > patch releases will be the positive side effect of faster
> > > testing/releases
> > > > and adopting some specification like semver.
> > > >
> > > > - Dave
> > > >
> > > > -----Original Message-----
> > > > From: ctubbsii@gmail.com [mailto:ctubbsii@gmail.com] On Behalf Of
> > > > Christopher
> > > > Sent: Thursday, April 03, 2014 3:45 PM
> > > > To: Accumulo Dev List
> > > > Subject: Re: [DISCUSS] Bugs-only strictness for bugfix releases
> > > >
> > > > I don't think that's it's quite true to say '1.major.minor' is our de
> > > facto
> > > > scheme. Once again, I think many of us have always viewed it as
> > > > '1.long-term-support.bugfix'.
> > > >
> > > > --
> > > > Christopher L Tubbs II
> > > > http://gravatar.com/ctubbsii
> > > >
> > > >
> > > > On Thu, Apr 3, 2014 at 3:39 PM, Bill Havanki <
> > bhavanki@clouderagovt.com>
> > > > wrote:
> > > >> I agree with Christopher in principle, but I share Sean's concern
> > > >> about the versioning situation. Right now, the *de facto* versioning
> > > >> scheme is 1.major.minor. We should just adopt semantic versioning
> (or
> > > >> similar) and then enforce bugs-only for bugfix releases. This gives
> us
> > > the
> > > >> room we need.
> > > >>
> > > >> For reference: semver.org
> > > >>
> > > >>
> > > >> On Thu, Apr 3, 2014 at 3:24 PM, Sean Busbey
> > > >> <busbey+lists@cloudera.com>wrote:
> > > >>
> > > >>> -1
> > > >>>
> > > >>> Until we have a full discussion on compatibility and what we're
> going
> > > >>> to mean for version numbers, this is counter productive to our
> > > >>> volunteer-driven CtR process. That some of us choose to focus our
> > > >>> resources on more recent major versions is irrelevant.
> > > >>>
> > > >>> Right now, we conflate minor and bugfix versions. This change would
> > > >>> mean instead conflating our major and minor versions. That's going
> to
> > > >>> make it harder for people to upgrade for compatible improvements
> > > >>> because the inclusion of the major changes will be disruptive.
> > > >>>
> > > >>> We need to have the compatibility and versioning discussion. This
> > > >>> band aid won't help.
> > > >>>
> > > >>>
> > > >>> On Thu, Apr 3, 2014 at 2:16 PM, John Vines <vines@apache.org>
> wrote:
> > > >>>
> > > >>> > +1
> > > >>> >
> > > >>> >
> > > >>> > On Thu, Apr 3, 2014 at 2:15 PM, Christopher <ctubbsii@apache.org
> >
> > > >>> > wrote:
> > > >>> >
> > > >>> > > JIRA JQL:
> > > >>> > > 'project = ACCUMULO AND resolution = Unresolved AND type not in
> > > >>> > > (Sub-task, Bug) AND fixVersion in (1.4.6,1.5.2,1.6.1)'
> > > >>> > >
> > > >>> > > There are 32 outstanding issues not marked as "Bugs" planned
> for
> > > >>> > > bugfix releases. This seems inappropriate to me. I would prefer
> > > >>> > > to be very strict about the right-most segment of a version
> > > >>> > > number, by defining it as "for bugfix releases", and by
> following
> > > >>> > > the rule: if the issue doesn't fix a bug, then it doesn't go
> in a
> > > >>> > > bugfix release.
> > > >>> > >
> > > >>> > > This strictness could help us focus on fixing and supporting
> > > >>> > > actual bugs in previous releases, without being bogged down by
> > > >>> > > non-bugs, it could help focus improvements in the latest
> version
> > > >>> > > and encourage more rapid releases, and give users more reasons
> to
> > > >>> > > upgrade. It would also help stabilize previous releases, by
> > > >>> > > avoiding the introduction of new bugs, which bodes well for
> > > long-term
> > > >>> > > support.
> > > >>> > >
> > > >>> > > I know we've previously talked about semver and other strict
> > > >>> > > versioning schemes, but regardless of whether we do any of
> those
> > > >>> > > other things, I think this strictness is the very least we
> could
> > > >>> > > do, and we could start encouraging this strictness today, with
> > > >>> > > minimal impact.
> > > >>> > > All it would take is to define the last segment of the
> versioned
> > > >>> > > releases as "for bugfix releases", regardless of defining the
> > > >>> > > rest of the version number (which can be discussed separately,
> > > >>> > > and this is a subset of most any versioning scheme we've
> > discussed
> > > >>> > > already).
> > > >>> > >
> > > >>> > > The implication is that some things we've done in the past to
> > > >>> > > "backport" improvements and features, which didn't address a
> bug,
> > > >>> > > would no longer be permitted. Or, at the very least, would have
> > > >>> > > been highly discouraged, or would have warranted a vote (see
> next
> > > >>> > > paragraph).
> > > >>> > >
> > > >>> > > As with anything, there may be important exceptions, so perhaps
> > > >>> > > with this strictness about "bugfix only for bugfix releases",
> we
> > > >>> > > could encourage (by convention, if not by policy) calling a
> vote
> > > >>> > > for non-bugfix changes, and rely on the veto for enforcement
> if a
> > > >>> > > non-bugfix was applied to a bugfix version. If we agree to this
> > > >>> > > strictness as a community, knowing a particular change is
> likely
> > > >>> > > to result in a veto can be a big help in discouraging
> violations.
> > > >>> > >
> > > >>> > > As a final note, I should mention that there are at least a few
> > > >>> > > of us who have been thinking about this last segment of the
> > > >>> > > version as "bugfix only" anyways, if only informally. The lack
> of
> > > >>> > > formalization/strictness about this, though, has permitted some
> > > >>> > > things in the past that are probably not the best ideas in
> terms
> > > >>> > > of stability and long-term support of previous release lines.
> > > >>> > > Hopefully, by adopting this strictness as a community, instead
> of
> > > >>> > > just informally in a few of our heads, we can all get on the
> same
> > > >>> > > page, and it will make the project better overall.
> > > >>> > >
> > > >>> > > --
> > > >>> > > Christopher L Tubbs II
> > > >>> > > http://gravatar.com/ctubbsii
> > > >>> > >
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> // Bill Havanki
> > > >> // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
> > > >
> > >
> >
> >
> >
> > --
> > Sean
> >
>

--089e013cc12a368f0204f673d0f7--