This is all really key to be honest. The only feature we need to develop today
is quality, and this is true regardless of 4.0.0. I've seen a lot of talk from
some quarters of a new approach to quality, but so far there have been few
contributions from the same quarters that materially contribute to it. With a
shift to discussing new feature development, it begins to look a bit empty.
Put some of that excitement for developing new features into developing new
approaches to assuring quality. I would love to see some CEP on this topic,
and I would consider it a worthwhile distraction to participate in those
discussions.
On 26/06/2020, 23:45, "David Capwell" <dcapw...@gmail.com> wrote:
>
> 1) changes going into beta should be small enough that a fast-forward
merge
>
should be available in the majority of cases up to trunk. We've done this
> with previous releases and it wasn't prohibitively expensive in terms of
> time. Further, I would posit that changes going into beta should be on the
> smaller side, further mitigating the burden of this process.
I don't have much experience here, but what I find is that a decent chunk
of the fixes I have been posting have to be rewritten for 2.2 (mostly CI),
3.0, 3.11, and trunk. This is currently already painful and makes me less
likely to want to fix things... If we branch 4.0 and people start
refactoring trunk, then there is even more burden to fix issues; I don't
see this as a small issue today.
2) We've been feature frozen since late 2018 with the expressed intention
> to encourage work on testing and stabilizing 4.0. I am not aware of any
> contributors whose time and energy has been invested in testing 4.0 that
> would otherwise have gone to trunk (i.e. this approach achieving its
> desired outcomes), however I do know of several major contributors and
> contributions that have atrophied and been deterred from further work on
> the project due to waiting for 4.0 to release.
When I joined this project I heard that Repair was a pinpoint for many, so
the first thing I did was look into why and started trying to fix bugs with
Repair. In doing this I found that the testing of repair is lacking and
that small regressions would not be caught by the current tests, so shifted
my focus to improving the testing rather than make the large changes I
wanted to make; my reasoning was simple, "if I can not rely on the existing
tests to show I didn't break anything, by fixing 1 problem I may break 10
others".
I was then later pulled off this into 3.x issues as many still struggle
upgrading from 2.1 to 3.x. I am currently weighted down by features which
are broken in 3.x (so have to rewrite them to be able to migrate), and a
constant stream of new data corruption bugs (I currently have 5 on my
plate). As I resolve the issues I see the common trend is "we lacked
testing in X".
Given the amount of data loss and corruption bugs that keep popping up, I
do feel it's reasonable to ask people to focus on testing rather than new
features. If we don't have a strong foundation we believe in, how do we
build a strong house on top?
I take the position that we should do everything
> reasonably possible to encourage a diversity of contributions to the
> project. I deeply believe that making deliberate decisions to prioritize
> new engagement and interaction on the project as the context in which it's
> used evolves is vital to the project's health long term.
I fully agree with this, which is why I feel the feature freeze is in the
best interest of the project and that we should be focusing on testing. The
hardest thing I have found is that adding a new feature is that there is an
unreasonable expectation of what you have to learn, their interactions, and
the ability to test their impact. Even simple things become hard given the
fact only committers can run Jenkins tests, or you pay money to be able to
run the tests... If the intent is to make it easier for new people to
contribute to the project, shouldn't the focus be on fixing their pain
points such as testing?
On Fri, Jun 26, 2020 at 3:38 PM Jordan West <jorda...@gmail.com> wrote:
> On Fri, Jun 26, 2020 at 2:58 PM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > > Nothing is stopping us for discussing CEPs now, and nothing prevents
> > folks from making their own feature branches.
> >
> > I disagree. CEPs are just as - if not more - of a distraction than
> > branching.
> >
>
> > Work doesn't happen in a vacuum. Those who are today focusing what
> > resources they can on shipping 4.0.0 will have to divert resources to
the
> > new CEP and feature development happening on the project. It is
> > unrealistic to expect otherwise.
> >
> > We can have a swifter 4.0.0 release, or we can begin earnestly
developing
> > new features, but we cannot have both.
> >
> >
> Agreed 100% and I would prefer to see us all focus on getting 4.0.0 out. I
> only meant we never explicitly voted to prevent CEPs from being submitted
> at this time and it was more in response to a comment in the initial email
> in this thread.
>
>
> >
> > On 26/06/2020, 22:09, "Jon Haddad" <j...@jonhaddad.com> wrote:
> >
> > We currently have 2.1, 2.2, 3.0 3.11, and trunk. With a new branch
> > we'll
> > _also_ have whatever is next, let's call it 5.0.
> >
> > Nothing is stopping us for discussing CEPs now, and nothing prevents
> > folks
> > from making their own feature branches.
> >
> > If we're going to add another branch (4.0) and let people merge to
> > trunk,
> > we're making an *active* decision to push the 4.0 release out even
> > further,
> > because the folks working on it will have to learn the new code when
> > they
> > merge forward.
> >
> > I'm -1 on branching before we release 4.0.
> >
> > On Fri, Jun 26, 2020 at 2:04 PM Mick Semb Wever <m...@apache.org>
> > wrote:
> >
> > > >
> > > > > Branching anytime before we 4.0.0 adds extra burden to the
> folks
> > trying
> > > > to
> > > > > get 4.0.0 out the door (because of merge up)
> > > >
> > > > Given both that we've done this with every major release in the
> > past, as
> > > > well as the type of work we'd expect to land during the beta
> phase
> > > > (smaller, non-api breaking, defect fixing or smaller performance
> > > tuning), I
> > > > didn't personally originally weigh this as being as much of a
> > burden as
> > > you
> > > > perceive it to be.
> > >
> > >
> > >
> > > Looking at this a different way, you might say we have previously
> > cut the
> > > release branch somewhere around beta. Because previous releases
> > haven't
> > > (all) had so much focus on testing and alphas. My impression is
> that
> > 4.0.0
> > > will be closer compared to a second or third patch of previous
> major
> > > releases.
> > >
> > > So I would have thought it makes sense around beta or RC to
branch,
> > > especially RC because between RC and GA it is more about a cooling
> > period,
> > > public acceptance and testing. That RC to GA window should be
quiet
> > enough
> > > that it makes sense to branch then, and kick off the CEP
> discussions.
> > >
> > > I don't think the forward merging really is so much of a problem,
> > it's a
> > > normal activity in the C* codebase, and the additional
> merge-forward
> > window
> > > between either beta or RC, to GA is short.
> > >
> > > Thanks Ekaterina and Benjamin and Josh for raising the discussion.
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
