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 > > >
