> > Lay our cards on the table about what we want included in 4.0 and work to > get those in
Are you saying we're back to where we started....? š For those wanting to delay, are we just dancing around inclusion of > some pet features? This is fine, I just think we need to communicate > what we are after if so. Mostly. There are numerous large tickets that have been being worked on *for a long time*, and have been rumoured to be nearing completion for some time, which would be beneficial for everyone. They aren't my pet tickets but I'd sure like to see them finally land (see: Apple tickets). But there's more to it than that. We've also got tickets we'd like to get committed and It's an incredibly slow process to get anyone to review your tickets (and commit) if you're not in the club, so to speak. There's 148 tickets that are Patch available ATM, 89 of which have no reviewer. I think it's highly unlikely a lot of these will get committed before June 1st, and I don't think that's fair on a lot of the people who have been trying to contribute their patches for months, potentially years in some cases, but have been stuck waiting on feedback/reviewers/committers. Sure it's not the end of the world, but I know from experience that it's damn discouraging. Even missing a minor release for a bug fix because of this is annoying as hell. I do want to remind everyone though that each new feature is at odds > with our stability goals for 4.0. With all the refactoring that's already gone into 4.0 and our current lack of testing I think we're fighting an uphill battle here anyway. Adding a few more metres is the least of our worries IMO. The alpha/verification/testing period is already going to be a very long one. On 6 April 2018 at 04:01, Nate McCall <zznat...@gmail.com> wrote: > >> > >> So long as non-user-visible improvements, including big ones, can still > go > >> in 4.0 at that stage, Iām all for it. > > > > > > My understanding is that after June 1st the 4.0 branch would be created > and > > would be bugfix only. It's not really a feature freeze if you allow > > improvements after that, which is why they'd instead go to trunk. > > > > I'm also on the "too soon" train so pushing it back to August or so is > > desirable to me. > > > > For those wanting to delay, are we just dancing around inclusion of > some pet features? This is fine, I just think we need to communicate > what we are after if so. > > We can do two things: > 1. Lay our cards on the table about what we want included in 4.0 and > work to get those in > 2. Agree to keep June 1 follow up a lot quicker with a 4.1 > > I do want to remind everyone though that each new feature is at odds > with our stability goals for 4.0. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
