On Wed, 9 Sep 2020 at 01:46, Laszlo Kishalmi <laszlo.kisha...@gmail.com> wrote: > Freeze times: 11.2, 11.3, 12.0, and 12.1 are 40, 36, 85, and 51 days > that's 212 days in a year. That's a lot. > > So while the idea cutting the release branch out of master on the > expense of have a small freeze, however nice, elegant and simple, it > does not seem to work good enough.
Agreed! Freezes, *if* they lead to no new code being integrated, are too long. But let's not forget that issue was foreseen and discussed quite a lot last year - there is no reason that "freezing" master has to mean no new feature integration work can progress. I also think frozen is the wrong word, really - it's a consolidation phase where issues are addressed. There were 36 PRs integrated during the freeze. Another issue with the length of the freeze periods is actually us not being strict enough on cut off dates, or blocking issues not being addressed earlier in the process. Last freeze could probably have been 14 days shorter if we'd rejected nb-javac 14 for being late - things need to land in master earlier! Not the week before or after freeze. Being stricter on that could definitely result in a ~3 week freeze. There was also pressure to ensure 12.1 had "enough" features! Also, LTS / NetCAT duration, and how that's done, is probably a different issue to consider - that's a broader one that we never really resolved. > As of the mentioned problems during the 9, 10, 11 cycle about the > diverging source code.... While it caused some headaches especially for me, I > did > not feel that difficult to manage those issues. I'd have to look back for certain - there were a couple of issues that regressed between releases that IMO showed a problem. Not that the current release process is the only way of addressing that, obviously. > 2. manage one and two half branches: master + next + release. During > release period: next branch serves for integration. > > Neil proposed something like option number 2. There is no spoon! For all intents and purposes we release off of master. Release branch is just an artefact of the CI process until after master is unfrozen (spec versions increased). So it's really master + next. The next branch was also not really my proposal - it's one of the options brought up in the discussion about this last time. It adds one branch for next release feature integration. Changing the base branch for any open PR is literally a case of clicking edit at the top - it's probably the easiest approach available to keeping development active? > In that way we do not have two roles for master branch. Master only has one role now - it is always the next scheduled release. Personally, I think we can address the issues without changing that fact. I have a preference for as simple as works, which may mean dropping freeze or it may not. Anyway, interested in wider opinions here - same as previous decision on this, needs to be not RM-centric! :-) Best wishes, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
