Hi,
I am +1 on freezing features at some point.
Here are my thoughts
1. The reason it took 1.5 years b/w 3.0 and 4.0 is because 3.0 was
released(not cut) too early. There were so many critical bugs in it for
months after the release. Most people have just finished or about to
upgrade to 3.0. (Please correct me if my understanding is wrong)
2. We should cut(not release) the branch when some of it is true. I am not
sure which ones are must in this list and we should discuss.
a. Huge change log(This is true). The change log is also not growing very
quickly which is bad for project but beneficial for this.
b. Which people are willing to start testing the next day it is cut.
c. Do we have resources to fix the critical bugs. What if we find bugs and
no one is available to fix/review them. Can someone sign up for this.
d. Do we have resources to fix all Dtest including upgrade tests.
Thanks,
Sankalp
On Tue, Apr 10, 2018 at 9:55 AM, Eric Evans <john.eric.ev...@gmail.com>
wrote:
> On Mon, Apr 9, 2018 at 3:56 PM, Jonathan Haddad <j...@jonhaddad.com> wrote:
>
> [ ... ]
>
> > 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.
>
> This sounds right to me. Bigger, destabilizing changes should land at
> the beginning of the cycle; Setting up a mad rush at the end of a
> release cycle does not yield favorable results (we've done this, we
> know).
>
> > 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."
>
> Unfortunately, when stability suffers things get "exciting" for all
> sorts of unintended reasons. I'm personally not umm, excited, by that
> prospect.
>
>
> --
> 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
>
>
