Re: 3.0 and the Cassandra release process
Can I regard the odd version as the "development preview" and the even version as the "production ready"? IMO, as a database infrastructure project, "stable" is more important than other kinds of projects. LTS is a good idea, but if we don't support non-LTS releases for enough time to fix their bugs, users on non-LTS release may have to upgrade a new major release to fix the bugs and may have to handle some new bugs by the new features. I'm afraid that eventually people would only think about the LTS one. 2015-03-19 8:48 GMT+08:00 Pavel Yaskevich : > +1 > > On Wed, Mar 18, 2015 at 3:50 PM, Michael Kjellman < > mkjell...@internalcircle.com> wrote: > > > For most of my life I’ve lived on the software bleeding edge both > > personally and professionally. Maybe it’s a personal weakness, but I > guess > > I get a thrill out of the problem solving aspect? > > > > Recently I came to a bit of an epiphany — the closer I keep to the daily > > build — generally the happier I am on a daily basis. Bugs happen, but for > > the most part (aside from show stopper bugs), pain points for myself in a > > given daily build can generally can be debugged to 1 or maybe 2 root > > causes, fixed in ~24 hours, and then life is better the next day again. > In > > comparison, the old waterfall model generally means taking an “official” > > release at some point and waiting for some poor soul (or developer) to > > actually run the thing. No matter how good the QA team is, until it’s > > actually used in the real world, most bugs aren’t found. > > > > If you and your organization can wait 24 hours * number of bugs > discovered > > after people actually started using the thing, you end up with a “usable > > build” around the holy-grail minor X.X.5 release of Cassandra. > > > > I love the idea of the LTS model Jonathan describes because it means more > > code can get real testing and “bake” for longer instead of sitting > largely > > unused on some git repository in a datacenter far far away. A lot of code > > has changed between 2.0 and trunk today. The code has diverged to the > point > > that if you write something for 2.0 (as the most stable major branch > > currently available), merging it forward to 3.0 or after generally means > > rewriting it. If the only thing that comes out of this is a smaller delta > > of LOC between the deployable version/branch and what we can develop > > against and what QA is focused on I think that’s a massive win. > > > > Something like CASSANDRA-8099 will need 2x the baking time of even many > of > > the more risky changes the project has made. While I wouldn’t want to > run a > > build with CASSANDRA-8099 in it anytime soon, there are now hundreds of > > other changes blocked, most likely many containing new bugs of their own, > > but have no exposure at all to even the most involved C* developers. > > > > I really think this will be a huge win for the project and I’m super > > thankful for Sylvian, Ariel, Jonathan, Aleksey, and Jake for guiding this > > change to a much more sustainable release model for the entire community. > > > > best, > > kjellman > > > > > > > On Mar 18, 2015, at 3:02 PM, Ariel Weisberg < > ariel.weisb...@datastax.com> > > wrote: > > > > > > Hi, > > > > > > Keep in mind it is a bug fix release every month and a feature release > > every two months. > > > > > > For development that is really a two month cycle with all bug fixes > > being backported one release. As a developer if you want to get something > > in a release you have two months and you should be sizing pieces of large > > tasks so they ship at least every two months. > > > > > > Ariel > > >> On Mar 18, 2015, at 5:58 PM, Terrance Shepherd > > wrote: > > >> > > >> I like the idea but I agree that every month is a bit aggressive. I > > have no > > >> say but: > > >> > > >> I would say 4 releases a year instead of 12. with 2 months of new > > features > > >> and 1 month of bug squashing per a release. With the 4th quarter just > > bugs. > > >> > > >> I would also proposed 2 year LTS releases for the releases after the > 4th > > >> quarter. So everyone could get a new feature release every quarter and > > the > > >> stability of super major versions for 2 years. > > >> > > >> On Wed, Mar 18, 2015 at 2:34 PM, Dave Brosius < > dbros...@mebigfatguy.com > > > > > >> wrote: > > >> > > >>> It would seem the practical implications of this is that there would > be > > >>> significantly more development on branches, with potentially more > > >>> significant delays on merging these branches. This would imply to me > > that > > >>> more Jenkins servers would need to be set up to handle auto-testing > of > > more > > >>> branches, as if feature work spends more time on external branches, > it > > is > > >>> then likely to be be less tested (even if by accident) as less > > developers > > >>> would be working on that branch. Only when a feature was blessed to > > make it > > >>> to the release-tracked branch, would it become exp
Re: 3.0 and the Cassandra release process
+1 to this general proposal. I think the time has finally come for us to try something new, and this sounds legit. Thanks! On Thu, Mar 19, 2015 at 12:49 AM, Phil Yang wrote: > Can I regard the odd version as the "development preview" and the even > version as the "production ready"? > > IMO, as a database infrastructure project, "stable" is more important than > other kinds of projects. LTS is a good idea, but if we don't support > non-LTS releases for enough time to fix their bugs, users on non-LTS > release may have to upgrade a new major release to fix the bugs and may > have to handle some new bugs by the new features. I'm afraid that > eventually people would only think about the LTS one. > > > 2015-03-19 8:48 GMT+08:00 Pavel Yaskevich : > > > +1 > > > > On Wed, Mar 18, 2015 at 3:50 PM, Michael Kjellman < > > mkjell...@internalcircle.com> wrote: > > > > > For most of my life I’ve lived on the software bleeding edge both > > > personally and professionally. Maybe it’s a personal weakness, but I > > guess > > > I get a thrill out of the problem solving aspect? > > > > > > Recently I came to a bit of an epiphany — the closer I keep to the > daily > > > build — generally the happier I am on a daily basis. Bugs happen, but > for > > > the most part (aside from show stopper bugs), pain points for myself > in a > > > given daily build can generally can be debugged to 1 or maybe 2 root > > > causes, fixed in ~24 hours, and then life is better the next day again. > > In > > > comparison, the old waterfall model generally means taking an > “official” > > > release at some point and waiting for some poor soul (or developer) to > > > actually run the thing. No matter how good the QA team is, until it’s > > > actually used in the real world, most bugs aren’t found. > > > > > > If you and your organization can wait 24 hours * number of bugs > > discovered > > > after people actually started using the thing, you end up with a > “usable > > > build” around the holy-grail minor X.X.5 release of Cassandra. > > > > > > I love the idea of the LTS model Jonathan describes because it means > more > > > code can get real testing and “bake” for longer instead of sitting > > largely > > > unused on some git repository in a datacenter far far away. A lot of > code > > > has changed between 2.0 and trunk today. The code has diverged to the > > point > > > that if you write something for 2.0 (as the most stable major branch > > > currently available), merging it forward to 3.0 or after generally > means > > > rewriting it. If the only thing that comes out of this is a smaller > delta > > > of LOC between the deployable version/branch and what we can develop > > > against and what QA is focused on I think that’s a massive win. > > > > > > Something like CASSANDRA-8099 will need 2x the baking time of even many > > of > > > the more risky changes the project has made. While I wouldn’t want to > > run a > > > build with CASSANDRA-8099 in it anytime soon, there are now hundreds of > > > other changes blocked, most likely many containing new bugs of their > own, > > > but have no exposure at all to even the most involved C* developers. > > > > > > I really think this will be a huge win for the project and I’m super > > > thankful for Sylvian, Ariel, Jonathan, Aleksey, and Jake for guiding > this > > > change to a much more sustainable release model for the entire > community. > > > > > > best, > > > kjellman > > > > > > > > > > On Mar 18, 2015, at 3:02 PM, Ariel Weisberg < > > ariel.weisb...@datastax.com> > > > wrote: > > > > > > > > Hi, > > > > > > > > Keep in mind it is a bug fix release every month and a feature > release > > > every two months. > > > > > > > > For development that is really a two month cycle with all bug fixes > > > being backported one release. As a developer if you want to get > something > > > in a release you have two months and you should be sizing pieces of > large > > > tasks so they ship at least every two months. > > > > > > > > Ariel > > > >> On Mar 18, 2015, at 5:58 PM, Terrance Shepherd > > > > wrote: > > > >> > > > >> I like the idea but I agree that every month is a bit aggressive. I > > > have no > > > >> say but: > > > >> > > > >> I would say 4 releases a year instead of 12. with 2 months of new > > > features > > > >> and 1 month of bug squashing per a release. With the 4th quarter > just > > > bugs. > > > >> > > > >> I would also proposed 2 year LTS releases for the releases after the > > 4th > > > >> quarter. So everyone could get a new feature release every quarter > and > > > the > > > >> stability of super major versions for 2 years. > > > >> > > > >> On Wed, Mar 18, 2015 at 2:34 PM, Dave Brosius < > > dbros...@mebigfatguy.com > > > > > > > >> wrote: > > > >> > > > >>> It would seem the practical implications of this is that there > would > > be > > > >>> significantly more development on branches, with potentially more > > > >>> significant delays on merging these branches. This would im
Re: 3.0 and the Cassandra release process
Hi, I realized one of the documents we didn't send out was the infrastructure side changes I am looking for. This one is maybe a little rougher as it was the first one I wrote on the subject. https://docs.google.com/document/d/1Seku0vPwChbnH3uYYxon0UO-b6LDtSqluZiH--sWWi0/edit?usp=sharing The goal is to have infrastructure that gives developers as close to immediate feedback as possible on their code before they merge. Feedback that is delayed to after merging to trunk should come in a day or two and there is a product owner (Michael Shuler) responsible for making sure that issues are addressed quickly. QA is going to help by providing developers with a better tools for writing higher level functional tests that explore all of the functions together along with the configuration space without developers having to do any work other then plugging in functionality to exercise and then validate something specific. This kind of harness is hard to get right and make reliable and expressive so they have their work cut out for them. It's going to be an iterative process where the tests improve as new work introduces missing coverage and as bugs/regressions drive the introduction of new tests. The monthly retrospective (planning on doing that first of the month) is also going to help us refine the testing and development process. Ariel On Thu, Mar 19, 2015 at 7:23 AM, Jason Brown wrote: > +1 to this general proposal. I think the time has finally come for us to > try something new, and this sounds legit. Thanks! > > On Thu, Mar 19, 2015 at 12:49 AM, Phil Yang wrote: > > > Can I regard the odd version as the "development preview" and the even > > version as the "production ready"? > > > > IMO, as a database infrastructure project, "stable" is more important > than > > other kinds of projects. LTS is a good idea, but if we don't support > > non-LTS releases for enough time to fix their bugs, users on non-LTS > > release may have to upgrade a new major release to fix the bugs and may > > have to handle some new bugs by the new features. I'm afraid that > > eventually people would only think about the LTS one. > > > > > > 2015-03-19 8:48 GMT+08:00 Pavel Yaskevich : > > > > > +1 > > > > > > On Wed, Mar 18, 2015 at 3:50 PM, Michael Kjellman < > > > mkjell...@internalcircle.com> wrote: > > > > > > > For most of my life I’ve lived on the software bleeding edge both > > > > personally and professionally. Maybe it’s a personal weakness, but I > > > guess > > > > I get a thrill out of the problem solving aspect? > > > > > > > > Recently I came to a bit of an epiphany — the closer I keep to the > > daily > > > > build — generally the happier I am on a daily basis. Bugs happen, but > > for > > > > the most part (aside from show stopper bugs), pain points for myself > > in a > > > > given daily build can generally can be debugged to 1 or maybe 2 root > > > > causes, fixed in ~24 hours, and then life is better the next day > again. > > > In > > > > comparison, the old waterfall model generally means taking an > > “official” > > > > release at some point and waiting for some poor soul (or developer) > to > > > > actually run the thing. No matter how good the QA team is, until it’s > > > > actually used in the real world, most bugs aren’t found. > > > > > > > > If you and your organization can wait 24 hours * number of bugs > > > discovered > > > > after people actually started using the thing, you end up with a > > “usable > > > > build” around the holy-grail minor X.X.5 release of Cassandra. > > > > > > > > I love the idea of the LTS model Jonathan describes because it means > > more > > > > code can get real testing and “bake” for longer instead of sitting > > > largely > > > > unused on some git repository in a datacenter far far away. A lot of > > code > > > > has changed between 2.0 and trunk today. The code has diverged to the > > > point > > > > that if you write something for 2.0 (as the most stable major branch > > > > currently available), merging it forward to 3.0 or after generally > > means > > > > rewriting it. If the only thing that comes out of this is a smaller > > delta > > > > of LOC between the deployable version/branch and what we can develop > > > > against and what QA is focused on I think that’s a massive win. > > > > > > > > Something like CASSANDRA-8099 will need 2x the baking time of even > many > > > of > > > > the more risky changes the project has made. While I wouldn’t want to > > > run a > > > > build with CASSANDRA-8099 in it anytime soon, there are now hundreds > of > > > > other changes blocked, most likely many containing new bugs of their > > own, > > > > but have no exposure at all to even the most involved C* developers. > > > > > > > > I really think this will be a huge win for the project and I’m super > > > > thankful for Sylvian, Ariel, Jonathan, Aleksey, and Jake for guiding > > this > > > > change to a much more sustainable release model for the entire > > community. > > > > > >
