accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Bugs-only strictness for bugfix releases
Date Mon, 07 Apr 2014 14:48:27 GMT
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
View raw message