On Tue, 8 Dec 2020 at 05:45, Laszlo Kishalmi <[email protected]> wrote: > As version 12.2 got out,
Congratulations! And thanks. > - Well, the release is out, we almost made that in our projected > timeframe. (One of our fastest releases) I make it third out of the five update releases .. more on speed below .. > - It seems managing the master, delivery and release branches worked > well without headache or too much overhead. I'd thank the contributors > to play well with the rules and supporting my requests. It is about 40+ > PR got merged into master while we were still working on the release > stabilization. Yes, seems to have been a really good solution! Any issues on your end in merging delivery branch? Any PRs actually held up from merging to master? Temporary delivery branch just an artefact of our current build process, or actually useful to keep in the process? > increased activity around the PR processing. What about JIRA processing this time? It's the aspect I feel got worse and harder to manage over release cycles I've RM'd. > - Well, the release speed is still not there where we imagined. But can it be improved?! We seem to have stabilised at a similar release speed. It's reliant on adequate testing and fixes being proposed for criticals / blockers. Can that really be sped up in practice? Because we haven't so far. Still, most delays have been macOS or nb-javac related ... What about installers? Some delays caused by inadequate testing there - is there any way to automate the installer process with code signing? And deliver for betas / rcs? And then we could do with trying to get back to binary votes being roughly parallel with release vote? > - Early feedback! ... So instead of voting 0 (saying meh), reason! +1 to that. And if not sure if something should be a blocker, discussion thread off the vote thread (and ideally before it)? > - We need to add an API change review round even before branching for > the release. +1. Also not helped in that I'd not followed up properly on post-12.1 discussion to get that in place for freeze. But agree, before freeze would be more helpful. This one seemed "worse" too. I feel there were things in there that should have been breaking some tests?! And picking up at PR time, not release, would have been better? > - We still do not have a definitive answer, what do we want from an LTS > release (or do we want it all). Drop it! ;-) > - We still have not decided how the 12.3 and 13.0 would relate to each > other. (as the other side of the LTS topic) Or if we keep, your previous suggestion of LTS being built off of x.3? As long as we find a way to ensure fixes for LTS hit master. And start NetCAT on 12.3 release date? I also dislike we voted on a versioning scheme before we even decided what our release strategy was, and it keeps confusing people - so maybe after 12.3, the outward facing branding goes something more like 13.0 LTS, 14.0, 14.1, 14.2, 14.3 LTS? Or just 13 LTS, 14, 15, 16, 17 LTS? And speaking of confusions, we need to think about how the Check for Updates UI relates to informing users of both LTS and non-LTS availability. > - Our love and hate relationship to nb-javac needs to be resolved. We > suggest people to go without it, then we suggest people to try that. > Also with the current release we see an increased amount of NPE-s and > parsing errors. If we would like to have it around, maybe we need to > able to patch it, even if outside Apache. But at the moment even me the > latest RM do not know what to think about that. Drop it! ;-) Or if we keep it, then absolutely in favour of Matthias' blocker for next release. Move to delivering nb-javac via Maven and plugin portal. Previous releases have been delayed by nb-javac not landing before freeze, and not being adequately tested. Even landing at freeze feels too late. And the third-party UC is another cause of problems, and we shouldn't need an IDE release just to deliver an nb-javac update? To deliver nb-javac via plugin portal we would also need a per release catalog - not just 11, 12, etc. And possibly one explicitly for dev. If nb-javac stays then is a snapshot version in dev (for master) that tracks upstream javac commits feasible? That process feels like it could be partly automated, but not here obviously! 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
