Hi Neil,
I believe part of the problem was that we had issues with 2 of 3 build
clusters. Travis didn't want to build [1] (basically just like right now
when we have a queue time of ~24h for some reason) and Jenkins had
problems too which is probably even worse during release.
This caused PRs to pile up and added at least one extra RC, which in
turn also added more opportunities to integrate more PRs etc.
There was also the incident when we lost ~2 PRs from the delivery branch
which also caused an extra RC. To avoid this in future, we should double
check the sync PRs before merging, to make sure everything is in it.
Lets do a proper review as if it is a regular PR (maybe put the authors
of the PRs which got merged during RC on the reviewer list?).
We should also spend more time trying to make tests fast and reliable
since this is actually something we can influence. Long queue times
become less of a problem if we don't have to restart jobs like playing
whack a mole ;)
best regards,
michael
[1] https://issues.apache.org/jira/browse/INFRA-23257
On 29.06.22 16:16, Neil C Smith wrote:
Hi Eric, Martin, Geertjan .. and everyone else,
Just thought I'd kick off a thread as it's getting near branching time
again. Seems to come around quicker every time! I also realised I
don't think we had the usual postmortem thread on NB14 either. Any
points, changes, etc. to address for 15?
Few from me would be -
There were a couple of PRs in NB14 that to me didn't really meet the
criteria for merging to delivery, one which potentially held the
release up. It's not a release team job to decide what gets merged -
that's for all reviewers. And primarily, in my mind, the PR author
should be making the initial call. I'd like to suggest that all
descriptions on PRs for delivery, at least when not linked to an
issue, should include a short justification for inclusion. Thoughts?
On PRs, Martin, can you handle reviewing and merging delivery PRs (or
parts) that are VSCode related? Obviously need to schedule around
syncing and RC builds. Whenever I merge to delivery, I try to test
the fix, check for potential conflicts, think about highlighting in RC
emails, etc. But for me that's with the IDE in mind rather than the
VSCode plugin.
As discussed elsewhere, I've added a GitHub label for Highlight, to
try and start flagging PRs that are changes to highlight in release
notes, announcements, etc. Possibly need to apply some
retrospectively for 15.
I should be OK for all of this release cycle - sorry I had to duck out
for much of the last one. I'm happy to handle the initial branch and
configuration around July 15th, unless anyone else wants to? Anyone
else got commitments, holidays, etc. to consider this time around?
Summer release always a fun one.
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
---------------------------------------------------------------------
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
