That should read "that could be a good thing" (rather than "that's a good thing"... I don't know which procedure is better).
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 6:05 PM, Christopher <ctubb...@apache.org> wrote: > 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
