Hi, Well, it would be interesting for us, mere users, to have something good out of the box than something average or unstable.
Speaking of the release of 1.0, it was clearly an alpha release - it took obviously quite some time to get issues fixed. It seems 1.1 is getting the same way, unfortunately. I'm really worried about release quality and not about months between releases. Getting the things out in time by any mean is a non-sense - it would be better to postpone a release if quality is not met. All in all, I do not care about 4, 6 or 9 months release cycle as soon as the release is rock solid. - Pierre -----Original Message----- From: Eric Evans [mailto:eev...@acunu.com] Sent: samedi 21 avril 2012 22:01 To: dev@cassandra.apache.org Subject: Re: 6 months a more realistic release cycle? On Sat, Apr 21, 2012 at 2:31 PM, Sylvain Lebresne <sylv...@datastax.com> wrote: > On Sat, Apr 21, 2012 at 7:59 PM, Eric Evans <eev...@acunu.com> wrote: >> I'm not opposed, but I'd rather see us try a longer release cycle >> before introducing too much rigor here. > > I had hoped that my suggestion above would not be felt as being > rigorous :(. At least that was not the intention. Sorry, I don't have any problems with those dates per say, what I meant was that with a longer release cycle, maybe we won't have to be any more strict about the deadline(s). > But to be clear, I don't want us to get too rigorous either. However, > and as much as I'm all for "let's all be smart", the project is > growing, we have more committers and we may get hopefully even more in > the future, and I think it's unrealistic to expect everyone to be on > the same page through some kind of magical mental communication. > Basically I don't want to impose rigor, I want to add some form of > schedule (on which we can all agree on) so that the project does goes > into the direction we all want to. Basically I think it's more easy > (and more sane) to agree a priori at least on the big picture, than to > have to react when you're not happy with how this go. It's more open > too. Yeah, that was sort of where I was going with the roadmap idea. Set the expectations up front so that people know what they're individually obligated to do in order to land a feature, as opposed to just setting a freeze date(s) (which seems to result in hurried 11th hour changes). There are all sorts of problems with the idea of a roadmap. For starters, we'd have to agree on the roadmap. :) 6 months is also a plenty of time for things to change, and make the roadmap irrelevant. I was just throwing it out there as one possible idea for avoiding scope creep. > But anyway, all I really want is for us developer to have 2 dates in > mind: "hum, I have to do that big issue before X if I want it in > version Y" and then "hum, I have to fix that small problem without > waiting to be 2 days before the release date because we need it in". > And I think it's just easier if those dates are fixed in advance. > > We could get even more fancy and write feature roadmap and whatnot, > but that was not even part of my suggestion and I think it would be > harder to do. Definitely harder, yes. -- Eric Evans Acunu | http://www.acunu.com | @acunu
