On Thu, Apr 12, 2018 at 4:07 AM, Sylvain Lebresne <lebre...@gmail.com> wrote: > I feel this discussion is starting to go in every directions and getting > farther away from any decision/progress so I'll attempt to summarize what I > hear, where I stand and *more importantly*, why. > > So as far as "what do we do for 4.0", I hear it boil down to 3 options: > 1) we freeze June 1. It says nothing on when we do release but starting > testing early, which also by extension limit the scope of what needs to be > tested, give believability in an earlier and more stable release. Everyone > seems to agree stability is good, and having no major release for too long > run the risk of everyone outside our own bubble thinking the project is > dead. > 2) we decide on a freeze date now, but later than June 1 (the question is > then "when?"). I'm listing this because there has been some explicit "+1 to > freezing but not June 1" but I'll admit I'm not entirely sure of the > reasoning behind this, and if there has been explicit argument for this, > I've missed them. > 3) we don't decide on a freeze date, 4.0 freeze is feature related. So we > build a list of features that needs to be in to freeze (which can have some > color for sure, some may be harder requirements than others). The best > argument I've heard for this is Blake's one, which is that people won't > truly test the release unless it is sexy (implying trunk isn't at all right > now) and that it would therefore yield more stability.
Personally, a sexy Cassandra release is one that doesn't cost me an inordinate amount of work and imperil my production clusters. A sexy Cassandra release is one with as few surprises as possible. I can't remember the last major release I thought was sexy. Additionally, I'm more likely to be able to spend time testing a new release, the more that work can be shown to move us closer to implementing it (which becomes more difficult as the delta increases). > As should be clear, I'm a proponent of 1 for the reasoning I expressed on > that point. I don't deny there is some logic behind the "it needs to be > sexy to be tested" argument for 3, but it's simply imo more risky, and too > much so. And this because: > 1) I'm convinced it will delay the release *a lot* in practice compared to > option 1 and I think we're underestimating the damage not releasing a major > for years will do to the project. > 2) it's all predicated on people doing unprecedented level of testing that > they wouldn't do if we go with option 1, but there is no historical > evidence to support the notion that it is a safe bet. If this doesn't > happen, which we *have* to consider, then the project will be in a *much* > worst state than with option 1. We'll have taken forever to release a less > stable release. +1 I think the way we address all those "sexy features" people want to get out, is by working to increase the release cadence (without increasing the burden on operators). Release early, release often. -- Eric Evans john.eric.ev...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
