The rate is already slow, but I understand your point. And, yes, you are correct, it would likely affect how far back developers finding bugs in newer versions look to determine the oldest affected version. In my view, that's a good thing, because it means less wasted effort if nobody is using those older versions. It puts a little more onus on users to report bugs against older versions when they encounter them, rather than developers to assume it's worth going back that far.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 4:22 PM, Sean Busbey <bus...@cloudera.com> 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 >> > > > > -- > Sean
