+1 for EOL of 1.5 with the release of 1.5.3 -----Original Message----- From: Christopher [mailto:ctubb...@apache.org] Sent: Thursday, May 21, 2015 1:18 PM To: Accumulo Dev List Subject: Re: [DISCUSS] EOL 1.5
So, at this point, I'm willing to do a 1.5.3 release and can start that today. It seems we're in agreement we should at least do that. Beyond that, I'm not really sure what the consensus is. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 10:35 PM, Josh Elser <josh.el...@gmail.com> wrote: > 1.5 has already started to suffer in terms of landing every bug-fix > there. I don't think it's intentional (I know I have done it though), > but it's kind of a sign that the devs have already mentally move beyond 1.5. > > I think JIRA is a clear sign that users aren't heavily using 1.5 (I > can't think of more than a couple tickets marked as affects 1.5.x), > but it would be nice to explicitly ask user@. > > A 1.5.3 to close things out would be nice -- can always be re-opened > if someone wants to scratch that itch. > > > Sean Busbey wrote: >> >> that change to development procedure will definitely impact them. >> it'll mean folks no longer look for their bugs to impact the 1.5 >> branch to start (unless things are critical). that basically >> guarantees that the rate of >> 1.5 releases will slow, which impacts ops planning for those on the >> 1.5 line. >> >> On Tue, May 12, 2015 at 2:42 PM, Christopher<ctubb...@apache.org> wrote: >> >>> Feel free to include user@ sooner, if you wish. The reason I hadn't >>> already was because my suggested route would only be a shift in >>> development procedures, and wouldn't really change things from a >>> user perspective. Alternatives to what I suggest may affect them >>> more strongly. We definitely should CC them when we have a decision, >>> though. >>> >>> -- >>> Christopher L Tubbs II >>> http://gravatar.com/ctubbsii >>> >>> >>> On Tue, May 12, 2015 at 2:55 PM, Sean Busbey<bus...@cloudera.com> wrote: >>>> >>>> oh! almost forgot. We should get user@accumulo into this >>>> conversation sooner rather than later. I'm not sure if it's better >>>> ot just copy them >>> >>> in >>>> >>>> to this thread or do it as a follow up once we have more of an idea >>>> of >>> >>> what >>>> >>>> "EOL" means for them. >>>> >>>> On Tue, May 12, 2015 at 1:53 PM, Sean Busbey<bus...@cloudera.com> >>> >>> wrote: >>>>> >>>>> +1 to making sure we have a 1.5.3 before stop dev >>>>> >>>>> I'd like to make sure we get through some testing of 1.5 -> 1.7 >>>>> upgrade testing before declaring dev over, just to give people >>>>> more assurance >>> >>> that >>>>> >>>>> they can upgrade off of the version. >>>>> >>>>> On Tue, May 12, 2015 at 1:18 PM, Christopher<ctubb...@apache.org> >>> >>> wrote: >>>>>> >>>>>> How do we want to EOL 1.5? >>>>>> >>>>>> Personally, I was thinking (soon after 1.7.0 is released): >>>>>> * Release and tag 1.5.3 >>>>>> * Remove 1.5 branch to focus active development on newer versions >>>>>> * Be willing to branch from the 1.5.3 tag to rapidly release a >>>>>> 1.5.4 in response to critical bugs >>>>>> >>>>>> My biggest concerns are: >>>>>> 1) We turn exhausted people off by doing burdensome release >>>>>> testing, which delays bugfixes in 1.5, and >>>>>> 2) We get into a situation where 1.5.3 has some bugs that we >>>>>> never fix, which sends a confusing message to stick with 1.5.2. >>>>>> >>>>>> There's also the concern that there's a fair amount of work that >>>>>> was put into 1.5.3, and I'd hate to have those contributions not >>>>>> be available to users of 1.5. >>>>>> >>>>>> I figure that so long as we're willing to fix critical bugs, we >>>>>> can formally cease active development (EOL), without going so far >>>>>> as to say that 1.5 users are completely screwed if a critical bug >>>>>> is identified. >>>>>> >>>>>> What I'm describing isn't really an EOL date, so much as an EOL >>>>>> period which begins when we cease active development on 1.5, and >>>>>> ends organically at some arbitrary point in the future when >>>>>> people stop reporting critical bugs (or we reach a point where >>>>>> maintaining it is too costly... a sort of "EOL-2"). >>>>>> >>>>>> Another way to look at what I'm suggesting is switch from a >>>>>> "sustained development" model to a "branch to fix and release" >>>>>> model, where patch/bugfix releases are more narrowly scoped and >>>>>> can occur more rapidly, on demand. >>>>>> >>>>>> Thoughts? Alternatives? Variations? Objections? >>>>>> >>>>>> -- >>>>>> Christopher L Tubbs II >>>>>> http://gravatar.com/ctubbsii >>>>>> >>>>> >>>>> >>>>> -- >>>>> Sean >>>>> >>>> >>>> >>>> -- >>>> Sean >> >> >> >> >
