Hi, Moving discussion on this off the [NOTICE] tagged thread - those are not meant to be too noisy ...
Laszlo made the following comments, which partly preempted my own thoughts on the problems / durations of master freeze ... my further thoughts below. On Sun, 6 Sep 2020 at 20:22, Laszlo Kishalmi <[email protected]> wrote: > I think we shall revisit this code freeze on master process. this time > the freeze period was about 50 days that's more than the half of a > release timeline. If the freeze would take 1-2 occasionally 3 weeks that > could be Ok. We are having advanced version control tools in our hand, > let's use them. In order to prove my point, I'd volunteer being the RM > for 12.2. > > There would be a feature freeze, but after the cut of the release branch > ad do the module version update, the master branch would be free for > merge. The PR-s patching the upcoming release will have a corresponding > PR for the master (or vice-versa). So yes there would be an overhead of > maintaining PR-s for two branches for a while, but at least it would > allow code be integrated and tested on master much longer. I'm personally dubious about dropping master freeze itself. At least without addressing all the reasons why it was there in the first place, and all the discussions that led to it. To all intents and purposes, master is our release branch. I remember Eric and I discussing whether to use branches or just tags of master for releases. As it is, we still have release branches more as a technical detail and for post-release updates right now. Master freezing wasn't originally my idea, but yes, I picked it out of the original discussions (and there were a few +1s to doing so), for a number of reasons. A key one IMO is that it means that at the start of each release cycle, HEAD is literally at the previous release - we're building on something that's been through some testing each time. So, while we can do multiple PR for bringing fixes into the release branch, there's a problem in a small number of cases where master and release have diverged and so the fix isn't the same - we had a number of issues recur between 9 -> 10 -> 11 because of that. That the release branch is effectively cut from master at release date rather than feature freeze is a positive?! At the time we decided on the current release strategy, the problem of master being frozen and holding up development was discussed quite a bit. As were some ideas for addressing that. Personally, I'd prefer we relooked at those first - master freezing itself isn't the issue, it's what that is leading to in terms of development stalling. PHP development has continued in a separate branch through master freezes. I'd be interested in Junichi and others' thoughts on how that has worked in practice? Why do we feel we need to unfreeze master to have code integrated and tested? One option we discussed last year was having a "next" branch through freeze (in fact, looking back, a suggestion from Jan alongside freeze!). ie. as soon as master freezes for release122, a next123 branch is cut. All PRs can be integrated and tested in that through the freeze period, and then after release a PR created to merge next123 to master, discussing and addressing any merge conflicts that arise. Fixes go directly in master, but can be pulled into the next branch if required. That way all new features get applied on top of the previous release version. Could that work? Does that address the concerns? Or do we need to reverse the idea of master freeze and meet any concerns in other ways? Either way we should discuss and then move via a lazy consensus thread if necessary. Best wishes, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
