Forking is a good idea.
On Mon, Apr 7, 2014 at 10:48 AM, Christopher <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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, <[email protected]> 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: [email protected] > >> > > To: [email protected] > >> > > 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: [email protected] [mailto:[email protected]] 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 < > >> [email protected]> > >> > > 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 > >> > >> <[email protected]>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 <[email protected]> > wrote: > >> > >>> > >> > >>> > +1 > >> > >>> > > >> > >>> > > >> > >>> > On Thu, Apr 3, 2014 at 2:15 PM, Christopher < > [email protected]> > >> > >>> > 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 > >> >
