On Mon, Apr 9, 2018 at 10:56 PM Jonathan Haddad <j...@jonhaddad.com> wrote:
> There's always more stuff to try to shoehorn in. We've done big releases > with all the things, it never was stable. We tried the opposite end of the > spectrum, release every month, that really wasn't great either. Personally > I'd be OK with stopping new features by the end of this month and aiming to > release a stable 4.0 when we agree we would be comfortable dogfooding it in > production at our own companies (in a few months), and aim for 4.1 (or 5.0 > I don't want to bikeshed the version) for pluggable storage and transient > replicas. If they're not close to finished now why even consider them for > the 4.0 release? They're so core they should be merged into trunk at the > beginning of the cycle for the follow up release in order to get as much > exposure as possible. > Agreed with that. The idea of freezing soon is in no way to say no to any particular feature. It is, to me, to recognize the following: 1) trunk has a pretty big changelog already. There may not be hugely user-visible sexy new features, but it's still quite a few incremental improvements (and among other things, there is a full change of the internode networking code, so it's not exactly only minor stuffs overall) and that's not a bad thing at all. 2) it is clear that a large amount of users wants more stability out of our release, and accumulating more ambitious changes on top of existing large ones is going to make things strictly less stable, it's just a fact. 3) whether we like it or not, not having a major release for a long long time negatively impact many people judgement of the liveness of the project (even with a freeze june 1, we're looking at likely a year and a half between major release). That negatively impact the project and imo we're not doing our PMC job right if we don't at least consider that. 4) what is there to lose in freezing 4.0 now/soon in the first place? That doesn't have to stop the development of any other feature for sure. So the only real downside I see is some of those features getting released a few months later than they would otherwise be. But 1) is that such a big deal? and 2) we kind of control our release schedule, so we can really control that downside. If by some miracle 4 or 5 amazing game-changing-that-everyone-needs-now features get simultaneously ready a short while after 4.0 is released, then let's just have a short cycle for 4.1/5.0. Anyway, I'm still personally very strongly in favor of a *strict* freeze on June 1 (I'm not really against a sooner freeze, but I'm happy giving us a small buffer to get a few current basically finished features in). > There's 148 tickets that are Patch available ATM, 89 of which have no reviewer. It's a good point and I wanted to highlight it as we clearly have a problem with reviews we should try to fix. That said, the only possible (long-term) real fix here is to collectively agree to spend more of our limited time reviewing contributions before working on our own pet tickets. And I do think we should do that (and I'll try to do my part more for what it's worth), but I do not think this should impact the when-4.0 discussion (though if we do make improvement on this, we might well be able to get a non negligible number of those in before June 1). -- Sylvain > > Jon > > On Mon, Apr 9, 2018 at 1:46 PM Nate McCall <zznat...@gmail.com> wrote: > > > > I'd like to see pluggable storage and transient replica tickets land, > for > > > starters. > > > > I think both those features are, frankly, necessary for our future. On > > the other hand, they both have the following risks: > > 1. core behavioral changes > > 2. require changing a (relatively) large surface area of code > > > > We can aim to de-risk 4.0 by focusing on what we have now which is > > solid repair and NIO internode (maybe we move the 4.0 branch timeline > > up?), aiming for a 4.1 following soon-ish. > > > > Or we can go in eyes open and agree on a larger footprint 4.0. > > > > I'm on the fence, tbh (can't emphasize enough how big both those > > features will be). I just want everyone to know what we are getting > > into and that we are potentially impacting our goals of "stable" == > > "exciting." > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
