If you all have never seen the movie "grandma's boy" I suggest it.
https://www.youtube.com/watch?v=uJLQ5DHmw-U There is one funny seen where the product/project person says something like, "The game is ready. We have fixed ALL THE BUGS". The people who made the movie probably think the coders doing dance dance revolution is funny. To me the funniest part of the movie is the summary statement that "all the bugs are fixed". I agree with Sylvain, that cutting branches really has nothing to do with "quality". Quality like "production ready" is hard to define. I am phrasing this next part as questions to encourage deep thought not to be a jerk. Someone jokingly said said 3.0 was the "break everything" release. What if 4.0 was the "fix everything" release? What would that mean? What would we need? No new features for 6 months? A vast network of amazon machines to test things? Jepsen ++? 24 hour integration tests that run CAS operations across a multi-node mixed version cluster while we chaos monkey nodes? Could we keep busy for 6 months just looking at the code and fix all the bugs for Mr. Cheezle? Could we fix ALL THE BUGS and then from that day it is just feature, feature, feature? We sit there and join and unjoin nodes for 2 days while running stress and at the end use the map reduce export and prove that not a single datum was lost? On Fri, Sep 16, 2016 at 2:42 PM, Sylvain Lebresne <sylv...@datastax.com> wrote: > On Fri, Sep 16, 2016 at 6:59 PM, Blake Eggleston <beggles...@apple.com> > wrote: > > > Clearly, we won’t get to this point right away, but it should definitely > > be a goal. > > > > I'm not entirely clear on why anyone would read in what I'm saying that it > shouldn't be a goal. I'm a huge proponent of this and of putting emphasis > on quality in general, and because it's Friday night and I'm tired, I'm > gonna add that I think I have a bigger track record of actually acting on > improving quality for Cassandra than anyone else that is putting word in my > mouth. > > Mainly, I'm suggesting that we don't have to tie the existence of a clearly > labeled stable branch (useful to user, especially newcomers) to future > improvement in the "releasability" of trunk in our design of a new release > cycle. If we do so, but releasability don't improve as quickly as we'd > hope, we penalize users in the end. Adopting a release cycle that ensure > said clearly labeled stable branch does exist no matter the rate of > improvement to the level of "trunk" releasibility is feels safer, and > doesn't preclude any effort in improving said releasibilty, nor > re-evaluating this in 1-2 year to move to release stable releases from > trunk directly if we have proven we're there. > > > > > > > On September 16, 2016 at 9:04:03 AM, Sylvain Lebresne ( > > sylv...@datastax.com) wrote: > > > > On Fri, Sep 16, 2016 at 5:18 PM, Jonathan Haddad <j...@jonhaddad.com> > > wrote: > > > > > > > > This is a different mentality from having a "features" branch, where > it's > > > implied that at times it's acceptable that it not be stable. > > > > > > I absolutely never implied that, though I willingly admit my choice of > > branch > > names may be to blame. I 100% agree that no releases should be done > > without a green test board moving forward and if something was implicit > > in my 'feature' branch proposal, it was that. > > > > Where we might not be in the same page is that I just don't believe it's > > reasonable to expect the project will get any time soon in a state where > > even a green test board release (with new features) meets the "can be > > confidently put into production". I'm not even sure it's reasonable to > > expect from *any* software, and even less so for an open-source > > project based on volunteering. Not saying it wouldn't be amazing, it > > would, I just don't believe it's realistic. In a way, the reason why I > > think > > tick-tock doesn't work is *exactly* because it's based on that > unrealistic > > assumption. > > > > Of course, I suppose that's kind of my opinion. I'm sure some will think > > that the "historical trend" of release instability is simply due to a > lack > > of > > effort (obviously Cassandra developers don't give a shit about users, > that > > must the simplest explanation). > > >
