RE: 6 months a more realistic release cycle?
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 wrote: > On Sat, Apr 21, 2012 at 7:59 PM, Eric Evans 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
Re: 6 months a more realistic release cycle?
On Sat, Apr 21, 2012 at 2:31 PM, Sylvain Lebresne wrote: > On Sat, Apr 21, 2012 at 7:59 PM, Eric Evans 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
Re: 6 months a more realistic release cycle?
On Sat, Apr 21, 2012 at 7:59 PM, Eric Evans 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. 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. 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. -- Sylvain
Re: 6 months a more realistic release cycle?
On Sat, Apr 21, 2012 at 10:17 AM, Sylvain Lebresne wrote: > +1 too. I also think it's a much more reasonable target. > > And I think that making our release schedule more reliable should be a > strong part of that change. For that, I wonder if having a more > organized QA period (basically a more codified release schedule) could > be beneficial. I won't hide that in my opinion our current > freeze-that-don't-freeze-much is not as much a useful tool than it > could be. I always assumed this was a symptom of a release cycle that was too short. > For instance, I could imagine something like: > - 4 month dev > - 2 month before release: soft freeze, where we stop including "big" > issues and re-prioritize issues needed to get a consistent release. We > could also release the first beta like a week max after that. > - 3 weeks before release: hard freeze, where we really do focus on > fixing bugs only > - 2 weeks before release: first RC release. > > I'll precise that what we have so far has only be a soft freeze. I do > think that having a hard freeze would be beneficial to improve the > final release reliability and help towards releasing on time. > > Of course, all this is open to discussion. I'm not opposed, but I'd rather see us try a longer release cycle before introducing too much rigor here. Maybe a roadmap would be helpful. Again, I think it's worth avoiding too much rigor, but if we agreed on the largish items to be done during a cycle up front, with gates at various stages (phase 1 by date A, phase 2 by date B, etc), we might keep the scope from creeping as easily. -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: 6 months a more realistic release cycle?
+1 too. I also think it's a much more reasonable target. And I think that making our release schedule more reliable should be a strong part of that change. For that, I wonder if having a more organized QA period (basically a more codified release schedule) could be beneficial. I won't hide that in my opinion our current freeze-that-don't-freeze-much is not as much a useful tool than it could be. For instance, I could imagine something like: - 4 month dev - 2 month before release: soft freeze, where we stop including "big" issues and re-prioritize issues needed to get a consistent release. We could also release the first beta like a week max after that. - 3 weeks before release: hard freeze, where we really do focus on fixing bugs only - 2 weeks before release: first RC release. I'll precise that what we have so far has only be a soft freeze. I do think that having a hard freeze would be beneficial to improve the final release reliability and help towards releasing on time. Of course, all this is open to discussion. -- Sylvain On Sat, Apr 21, 2012 at 2:30 PM, Brandon Williams wrote: > I am very +1 on this. I think Cassandra has matured to a point that > warrants this. > > On Fri, Apr 20, 2012 at 12:57 PM, Jonathan Ellis wrote: >> After the 0.7 release we decided to shoot for a fixed four-month >> release cycle. I think now is a good time to re-evaluate this, and >> possibly change to target a six month cycle: >> >> - Speaking for DataStax, about half our time is spent on maintenance. >> Given this, a 3 month window just isn't much time to work on some of >> the larger features we have planned. >> >> - Most of the schedule slip has been in our post-freeze QA period. A >> six month cycle would allow a more realistic 6 or even 8 weeks of QA, >> while still expanding the dev window. >> >> - Cassandra has matured enough that there is less low-hanging fruit to >> pick; two potential upgrades per year feels better matched to that, >> than three. >> >> - The reality has been that 0.8, 1.0, and 1.1 took about 5, 5.5, and 6 >> months, respectively. So in a sense, officially making it a 6-month >> cycle would only be acknowledging reality anyway. >> >> Thoughts? >> >> -- >> Jonathan Ellis >> Project Chair, Apache Cassandra >> co-founder of DataStax, the source for professional Cassandra support >> http://www.datastax.com
Re: 6 months a more realistic release cycle?
I am very +1 on this. I think Cassandra has matured to a point that warrants this. On Fri, Apr 20, 2012 at 12:57 PM, Jonathan Ellis wrote: > After the 0.7 release we decided to shoot for a fixed four-month > release cycle. I think now is a good time to re-evaluate this, and > possibly change to target a six month cycle: > > - Speaking for DataStax, about half our time is spent on maintenance. > Given this, a 3 month window just isn't much time to work on some of > the larger features we have planned. > > - Most of the schedule slip has been in our post-freeze QA period. A > six month cycle would allow a more realistic 6 or even 8 weeks of QA, > while still expanding the dev window. > > - Cassandra has matured enough that there is less low-hanging fruit to > pick; two potential upgrades per year feels better matched to that, > than three. > > - The reality has been that 0.8, 1.0, and 1.1 took about 5, 5.5, and 6 > months, respectively. So in a sense, officially making it a 6-month > cycle would only be acknowledging reality anyway. > > Thoughts? > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com
Re: 6 months a more realistic release cycle?
Sounds good to me, +1. -- Pavel Yaskevich On Saturday 21 April 2012 at 01:07, Eric Evans wrote: > On Fri, Apr 20, 2012 at 12:57 PM, Jonathan Ellis (mailto:jbel...@gmail.com)> wrote: > > After the 0.7 release we decided to shoot for a fixed four-month > > release cycle. I think now is a good time to re-evaluate this, and > > possibly change to target a six month cycle: > > > > - Speaking for DataStax, about half our time is spent on maintenance. > > Given this, a 3 month window just isn't much time to work on some of > > the larger features we have planned. > > > > - Most of the schedule slip has been in our post-freeze QA period. A > > six month cycle would allow a more realistic 6 or even 8 weeks of QA, > > while still expanding the dev window. > > > > - Cassandra has matured enough that there is less low-hanging fruit to > > pick; two potential upgrades per year feels better matched to that, > > than three. > > > > - The reality has been that 0.8, 1.0, and 1.1 took about 5, 5.5, and 6 > > months, respectively. So in a sense, officially making it a 6-month > > cycle would only be acknowledging reality anyway. > > > > Thoughts? > > I agree; +1 > > -- > Eric Evans > Acunu | http://www.acunu.com | @acunu > >
Re: 6 months a more realistic release cycle?
On Fri, Apr 20, 2012 at 12:57 PM, Jonathan Ellis wrote: > After the 0.7 release we decided to shoot for a fixed four-month > release cycle. I think now is a good time to re-evaluate this, and > possibly change to target a six month cycle: > > - Speaking for DataStax, about half our time is spent on maintenance. > Given this, a 3 month window just isn't much time to work on some of > the larger features we have planned. > > - Most of the schedule slip has been in our post-freeze QA period. A > six month cycle would allow a more realistic 6 or even 8 weeks of QA, > while still expanding the dev window. > > - Cassandra has matured enough that there is less low-hanging fruit to > pick; two potential upgrades per year feels better matched to that, > than three. > > - The reality has been that 0.8, 1.0, and 1.1 took about 5, 5.5, and 6 > months, respectively. So in a sense, officially making it a 6-month > cycle would only be acknowledging reality anyway. > > Thoughts? I agree; +1 -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: 6 months a more realistic release cycle?
We've been working on the 'ooh, shiny' approach to upgrading. Basically, once we see a new feature which will make life easier, better or just give us an excuse to play we start the process of adoption. Once we've managed to get our unit tests to pass, and updated our internal process documentation we then roll it out to our customers. We've never had a roll back, and each upgrade has pretty much been a dump -> install -> seed, and off we go. Hats of to the cassandra chaps, it just keeps getting better. -- Jools Enticknap Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Friday, 20 April 2012 at 19:33, Dave Brosius wrote: > +1 > > is there any stats on customer adoption of new versions? I'd wonder if > people generally move to new versions every 4 months, as that could be > potentially painful for them as well. Given the amount of questions > regarding older versions still percolating, i'd guess the answer is > they'd be ok with it too. > > > > On 04/20/2012 01:57 PM, Jonathan Ellis wrote: > > After the 0.7 release we decided to shoot for a fixed four-month > > release cycle. I think now is a good time to re-evaluate this, and > > possibly change to target a six month cycle: > > > > - Speaking for DataStax, about half our time is spent on maintenance. > > Given this, a 3 month window just isn't much time to work on some of > > the larger features we have planned. > > > > - Most of the schedule slip has been in our post-freeze QA period. A > > six month cycle would allow a more realistic 6 or even 8 weeks of QA, > > while still expanding the dev window. > > > > - Cassandra has matured enough that there is less low-hanging fruit to > > pick; two potential upgrades per year feels better matched to that, > > than three. > > > > - The reality has been that 0.8, 1.0, and 1.1 took about 5, 5.5, and 6 > > months, respectively. So in a sense, officially making it a 6-month > > cycle would only be acknowledging reality anyway. > > > > Thoughts?
Re: 6 months a more realistic release cycle?
+1 is there any stats on customer adoption of new versions? I'd wonder if people generally move to new versions every 4 months, as that could be potentially painful for them as well. Given the amount of questions regarding older versions still percolating, i'd guess the answer is they'd be ok with it too. On 04/20/2012 01:57 PM, Jonathan Ellis wrote: After the 0.7 release we decided to shoot for a fixed four-month release cycle. I think now is a good time to re-evaluate this, and possibly change to target a six month cycle: - Speaking for DataStax, about half our time is spent on maintenance. Given this, a 3 month window just isn't much time to work on some of the larger features we have planned. - Most of the schedule slip has been in our post-freeze QA period. A six month cycle would allow a more realistic 6 or even 8 weeks of QA, while still expanding the dev window. - Cassandra has matured enough that there is less low-hanging fruit to pick; two potential upgrades per year feels better matched to that, than three. - The reality has been that 0.8, 1.0, and 1.1 took about 5, 5.5, and 6 months, respectively. So in a sense, officially making it a 6-month cycle would only be acknowledging reality anyway. Thoughts?
