Hi, On Sat, 13 Jun 2020 at 03:10, Laszlo Kishalmi <[email protected]> wrote: > Apache NetBeans 12. has finally out in the wild, so I think it is time > to revise our release process.
Agreed! And thanks for kicking off. As discussed elsewhere, this is something I had planned to do in the next week or two - it's something we said we'd do now when agreeing the original schedule. > First of all, I would like you thank for the great job Eric did as > Release Manager during this long process. Thank you Eric! +1 Many thanks Eric! > These are my points below, it is not necessary complete, feel free to > extend and/or disagree. I'll add some comments inline - a lot I agree with, some I think we've veered off a little from what we originally agreed on. > 2. It seems the automatic release build improvements worked good, > requiring much less manual effort from the RM to produce release > packages. Definitely! Thanks Eric (primarily) again. > Me need to be improved, not try to pushing through half baked PRs > which also brake the builds. Please forgive me that! Or we need to prioritise having a testing process that's working and accurate! It is easier as an RM, too, if you don't have to read CI logs to work out whether a failing test is something that's failing spuriously and needs retriggering until it goes green, or is an actual problem that needs addressing. > The merge window was short as well. I know this is an LTS and NetCat > and everything, but seems having the master branch in release mode > for almost 3 months just does not seem to be right. It did feel more of an issue this time around. Although we also talked about having next / development branches to coalesce changes during freezes - we've only, IIRC, done this with PHP around 11.1. If there's a need that should be considered more, and might help with backlog of pending feature PRs - with downside that merging after freeze might become more complicated. > 3. We need to think about what really LTS means for us. > * Is it a less feature more NetCAT release? > Right now this is what I think we think of that, but it is > probably too vague > * Is it just a rounded up version of the latest x.3 version? > * Are we plan to do some regular patches for an LTS or just > essential security updates? > Right now, the last one, but is it Ok that way? It was intended to be all 3! I suggested based on two things - people wanting to keep NetCAT in a quarterly schedule somehow, and people concerned that updating every 3 months was too much for some education / corporate environments. I think we need to review whether either of the assumptions that was based on hold, and whether we should have an LTS at all! > 5. Piling up PR-s. Well this is an issue on every release. PR-s are > reviewed and merged in a campaign base. > We need to somehow encourage PR-s to get actually merged. I think this has become more of an issue recently - more below ... > We just cannot allow to have the master in feature freeze/release mode > for 6 months in a year (3x1 months for .x releases and 3 months for LTS) Agreed. But I also think quarterly releases without freeze is not feasible. Bear in mind the freeze period is meant to be concentrating on stabilising what's been merged. If we can keep that to 1 month in every 3 would that be good / better?! > I'd interpret the LTS release as a polished version of 11.3. Get NetCAT > test that version back and forth. That was the original intention, and kicking testing off on 11.3 was also discussed originally, and I tried to suggest we do this again a few months back. >We going to get a number of bugs to be > ironed out through NetCAT and other sources for the LTS release. > Occasionally we can haggle for a feature creep if really needed (vote on > it?). In 11.1 I did this via a lazy consensus thread for Payara and EE stuff. Made a rod for my own back in doing so, mind you! :-) But I think it's a good way to handle, but at RM discretion, because it's they who it potentially makes the most work for. > Having this, I'd not freeze the master for LTS. Let it have its > separate branch and separate life cycle. Fixes needed for LTS would > first go into master and have a twin PR for the LTS branch as well. To review, one of the reasons for freeze is that having master and release branch in sync makes it possible to have identical fixes in both - the more they diverge, the more likelihood that things behave differently, and the more likelihood that the fix in the next release isn't as stable as the previous one. I think we had problems between 9 and 10 like this, where the same issues recurred in 10? We could stop having LTS, and I am rather inclined to do so - we could leave it to third-party distributors to offer longer support / backport critical fixes? We could still have next .0 be the release after NetCAT on .3. If we keep LTS, we could have a month freeze again, then vote on a release candidate. We could have a month of that in the wild, with critical fixes on release branch and pushed via UC, while master is reopened for next release. Note, voting on a release candidate would also allow us to share more publicly (not that Geertjan doesn't already share the beta links widely! ;-) ) > On the PR-s. We should agree on a default merge policy. Something like: > If not stated otherwise, PRs with the following conditions shall be merged: > > * The CI checks are green > * No pending change request review. > * No labels against merge (work-in-progress, do-not-merge, etc. > * No open questions in the comments > * One of the following conditions fulfilled: > o All reviewer approved > o One reviewer approved and at least 3 days old > o At least 7 days old > > Anyone who has commit rights are entitled and encouraged to do the merge. Outside of freezes I agree with that, if by a committer. If opened by a non-committer we need to check more carefully authorship / IP, maybe require review. (Noting that a contributor does not, in general, require an ICLA - planning a thread on that). Inside of freezes, I'd like to keep (go back?) to the RM being the only person who merges. However, that is purely about scheduling. I'd really like to see us get back to a regular weekly beta during freezes - the RM being in charge of merging, checking the tests, and if necessary reverting is key to having timely betas (based on experience, not opinion!) Anything that met the above criteria, was labelled for release, and ready to merge by weekly beta cutoff, was merged during 11.1 and 11.2 - hence disagreement on the piling up PRs comment above! A general principle of, if the PR is ready to merge on Monday, it's in the beta on Wednesday (or whatever days suit the RM) is something I'd personally like to make a documented part of the release process. > During the release phase of a feature release we could select a few > bugfixes for a patch release which we can carry back to the LTS branch > and produce a patch release, probably a few weeks / a month after the > feature release. Of course if we have resources for that. Actually, whether we have an LTS or not, I'd suggest it's pushing critical fixes between release dates that's more important?! > Phew, this is what I have on my mind now. Remember this is a not a > statement, it is a discussion*. Feel free to join! Really useful! Hopefully comments don't seem too opposing - just concentrated on where my view differs a bit. Thanks and 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
