accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [DISCUSS] Bugs-only strictness for bugfix releases
Date Mon, 07 Apr 2014 14:54:20 GMT
Forking is a good idea.


On Mon, Apr 7, 2014 at 10:48 AM, Christopher <ctubbsii@apache.org> wrote:

> Mike,
>
> Bug would be non-conformance to intended/designed behavior, such that
> it causes failures in the application, regardless of who reported it.
> For instance, returning a null, when code that receives that returned
> value expects only non-null values, and the null value causes breakage
> in some way (intended action cannot be completed).
>
> Improvements would be things like "refactor internals to ease
> readability/writability", or "follow best practices", where the
> modifications don't result in an actual bug fix, but could help
> prevent future bugs. It could also be something where it's actually a
> bug (returning null values), but it cannot result in breakage, as that
> code path is never actually possible, and we just want to make the
> change to improve the API of that component, such that it will not
> result in a bug later if that code path does get exercised.
> Improvements could also be usability or minor modifications to an
> existing major feature (like adding a flag to sort the results, or
> adding an overloaded method which takes a String instead of byte[] for
> convenience).
>
> My intentions in updating these tickets had nothing to do with this
> issue, though (so perhaps we need to fork this thread?). Rather, they
> were routine quality checks in JIRA. My assumptions in these cases
> were that the reporter accepted the defaults instead of changing the
> issue type themselves. If that assumption is wrong, and they are
> actually resulting in bugs, I have no issue with documenting them as
> bugs. However, it would be nice if their descriptions included an
> explanation of the breakage, so that it's easy to understand as a bug.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> 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
> >>
>

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