Ok, I'm sorry for reaching the opposite conclusion before reading this email -
the implication here instead appears to be that, you believe, people are
advocating to integrate work that should be deferred - is that correct?
Perhaps we should have a direct conversation about the tickets you consider
this to be the case for?
FWIW, I don't think this is a rational strategy for appeasing anybody pushing
for inclusion in this release, given that cutting a new branch says nothing
about the timeline for its release.
On 26/06/2020, 19:58, "Joshua McKenzie" <jmcken...@apache.org> wrote:
I was speaking with Ekaterina and Benjamin about some of the currently
alpha scoped work which is what made me think of this dynamic. There's a
very different dynamic from "if we push this out to the next major, this
code will atrophy for 3-6 months" vs. "if we push this out to the next
major, you should still be able to merge this shortly so it's not as high a
merge cost."
Given our difficulty getting 4.0 out the door, my original thinking was
that having *less* disincentives to pushing out optional work would help us
make more objective decisions about when to hold a release for a ticket vs.
when to push the ticket. I suspect we'll go through something similar when
looking at the scope during beta for non-API breaking code that could
instead live in a patch release or a follow-up major. In my opinion we lack
clarity around scoping of this release and don't seem to have a
project-wide consensus on how we're handling this.
I'm reading an assumption that this is about CEP's and major features;
while there's a non-trivial body of work on the wiki as draft CEP's at this
time, those have not been brought to the mailing list out of respect for
multiple direct requests earlier this year not to distract from work on
getting 4.0 out the door.
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. I'm curious to hear more about this.
~Josh
On Fri, Jun 26, 2020 at 1:12 PM Jon Haddad <j...@jonhaddad.com> wrote:
> I was originally against the trunk freeze because I didn't want it to
> prevent progress, now I'm 100% on board with it and I think we should keep
> it in place till we release 4.0.0.
>
> 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), which means it'll take
> longer. Anyone taking issue with how long it's taken so far to get 4.0
out
> should recognize that if we branch and start allowing new features, we're
> going to take even longer to get 4.0 out. At this point 4.0 is turning
> into somewhat of a running joke, like Duke Nukem Forever.
>
> We can't have the next release come faster, merge new features, and have
> quality be up to the bar we've all aimed to achieve (classic good fast
> cheap scenario). We've got a tradeoff here. If folks are advocating we
> branch anytime before we release & unfreeze trunk, they'd better be
> prepared for the consequences of an even further delayed release. Did
> anyone ever think we'd possibly be frozen till 2021?
>
> After 4.0, we *really* need to start focusing on refactoring the codebase
> to improve modularity and testability so we don't have to ever go through
> this multi-year process again, because it's incredibly unhealthy to have
to
> freeze trunk this long. I think a lot of people are frustrated, and I get
> it, but I don't think the path to improving our collective position is to
> say "screw it" and branch any earlier than the 4.0.0 release.
>
>
>
> On Fri, Jun 26, 2020 at 9:26 AM Jordan West <jorda...@gmail.com> wrote:
>
> > Thanks for bringing this up Josh. I think the last time we all discussed
> > this on the mailing list was during the initial freeze thread where we
> > agreed "that between the September freeze date and beta, a new branch
> would
> > not be created and trunk would only have bug fixes and performance
> > improvements committed to it." Now that we are closer to beta and have a
> > more formal governance model I think its good to revisit.
> >
> > I'm torn. Folks should absolutely be able to scratch an itch as part of
> the
> > ethos of the project but we also haven't made substantial progress on
the
> > testing epic -- less than I expected when I was +1 to branch at beta in
> the
> > initial proposal. A few general thoughts come to mind around this:
> >
> > - Does not having a target branch truly discourage folks from scratching
> an
> > itch? Is the lack of a timeline on when they could actually see that
> merge
> > in a release more substantial?
> >
> > - Regarding timeline (and scope), I wonder if we would be better
> branching
> > after we have a bit more of an idea of our future process and
> development /
> > release lifecycle. Perhaps we should discuss that first?
> >
> > - I haven't seen any CEPs, etc for major features. These discussions
> aren't
> > blocked by the freeze and would presumably precede any need to merge to
> > trunk?
> >
> > - For smaller changes that don't need CEPs, I know maintaining a long
> > running branch can be a pain but I would like to better understand how
> many
> > of these are truly out there before asking the committers to maintain
and
> > merge into a 4th branch (which is not super challenging but is
measurable
> > overhead).
> >
> > Jordan
> >
> > On Fri, Jun 26, 2020 at 6:43 AM Joshua McKenzie <jmcken...@apache.org>
> > wrote:
> >
> > > As we close on cutting beta1, a new consequence of our release
> lifecycle
> > is
> > > becoming apparent. With guarantees of API stability in the beta phase,
> > any
> > > work that is deferred from alpha to the next major due to API
impacting
> > > changes will atrophy for as long as the beta is active.
> > >
> > > Cutting a branch for the 4.0 line upon release of beta1 would mitigate
> > this
> > > problem and allow work in flight to be merged in, as well as unblock
> the
> > > work of others who may not be focusing on testing 4.0, whether it be
> due
> > to
> > > their interest and focus or due to saturation on the work in scope for
> > the
> > > release.
> > >
> > > The obvious downsides to cutting a branch of a major and allowing dev
> on
> > > trunk to continue separately is 1) the need to merge up to trunk on
> > changes
> > > going into beta, and 2) a risk of a lack of focus on testing the
> release
> > > due to the availability of developing on trunk. My personal thoughts
on
> > > those two points:
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > I don't think it's appropriate for us as an existing body of
> contributors
> > > to mandate either how each other or more detrimentally how other new
> > > contributors engage with and contribute to the project by disallowing
> > > contributions past 4.0; 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.
> > >
> > > That's just my .02 - I'd be curious to hear what everyone else thinks.
> > >
> > > ~Josh
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
