Repository navigation
Highlight notable-changes of major releases in a TSC meeting #1371
Description
It can be difficult to determine which items should take priority when preparing for a major release due to differing perspectives and incomplete information. To address this, I suggest holding a TSC meeting immediately after the releaser announces a content freeze to establish the order of the CHANGELOG. This will help minimize the need for rework
Activity
BethGriggs commentedon Apr 13, 2023
+1 to a TSC review/tagged on the TSC agenda for review of the content prior to the release.
I think trying to establish a 'proper' order each time might just lead to more debate and effort, though. In the past, I tried to take the following approach:
Notable changessection.Notable changessection are organised alphabetically to remove any implied priority order.Other notable changesas a simple bullet list in the form generated by changelog-maker.That way there's no debate over ordering of the sections, and any contributor who would like their change highlighted as a dedicated heading just needs to supply their content. (As is similar to your request in nodejs/node#47381 (comment)).
I think it'd be better for us to end up with a default set of rules to apply than having to open the debate on ordering each time. Maybe @nodejs/release and @nodejs/tsc can work on defining those rules (or a template) ready for next time.
ronag commentedon Apr 13, 2023
TBH I think less structure here is preferable and the change log should be done at the releasers discretion.
BethGriggs commentedon Apr 13, 2023
Agreed on their discretion, we added 'The ultimate decision rests with the releaser.' in our changelog creation steps to clarify that stance.
But, we're also hoping to automate more of the release processes so it may be useful to define some high-level defaults/structures to enable that (nodejs/security-wg#860, nodejs/Release#821).
Trott commentedon Apr 14, 2023
I don't have my own independent opinion on how much the TSC should be involved, but if releasers are asking the TSC to do this, I think we should do it. I'm +1 on any reasonable request that reduces the hassle experienced by releasers.
So I'm +1 on this specifically because @RafaelGSS and @BethGriggs think it would be a good idea.
mcollina commentedon Apr 18, 2023
I'm +1 to delegate this to the sole discretion of the releaser shipping that version. This does not mean that feedback should not be considered but said feedback should not block a release.
ruyadorno commentedon Apr 18, 2023
First of all, sorry that I'm totally out of the loop (as I have been traveling this month and missed the last Release WG meeting) my perspective might be distorted on this topic so feel free to correct me or add any missing context.
That said, this proposal feels like (partially) taking away a mandate that is specifically defined in the Release WG charter. As a member of @nodejs/releasers that is not on the TSC I would like to understand why are we proposing that the TSC holds a meeting to define these notable changes (or anything else release-related really) instead of having the Release WG hosting that meeting.
I'm stating that, not as a complaint (personally from my point of view it has been difficult to find time to contribute in this first quarter, I'm def not looking for extra work 😂 ) but it's just that from a practical point of view the Release WG is a much more flexible forum (technically speaking anyone can join the zoom call for these meetings, while that's not the case with the TSC) such that we can invite any collaborators that might want to participate, while the releaser and the Release WG may still hold the final saying on any details.
BethGriggs commentedon Apr 18, 2023
Just for clarity, my +1 is only to having the proposal/content on the TSC agenda for visibility as a call for early input and review to reduce any last minute debate/rework.
Previously parts of the major release process were gated on TSC approval such as landing majors after the cut-off. We actively removed that in favour of more authority/autonomy of the Release WG and to reduce the bureaucracy of the process. I do agree we should not introduce a new requirement of TSC consensus for any part of the release process.
RafaelGSS commentedon Apr 18, 2023
The intention of having the content in the TSC agenda is to reduce any last-minute debate/rework and make sure the CHANGELOG + Blog posts are aligned with the Node.js project thoughts.
ruyadorno commentedon Apr 18, 2023
@BethGriggs @RafaelGSS Thanks for the clarification! May I suggest changing the title of this issue to:
Proposal: Highlight notable-changes of major releases in a TSC meeting
[-]Proposal: Define notable-changes of major releases in a TSC meeting[/-][+]Highlight notable-changes of major releases in a TSC meeting[/+]RafaelGSS commentedon Jul 14, 2023
Hey, @nodejs/releasers can we discuss it in the next meeting? It's almost time for a new major :)
RafaelGSS commentedon Jul 27, 2023
We've discussed it in today's meeting and we've decided to once the draft is ready, we use the
tsc-agendalabel to mention it regularly in TSC meetings so hopefully we'll avoid rework for Node.js 21. Closing it for now.RafaelGSS commentedon Jul 27, 2023
By the way, we need to adjust the label
release-agendatoRelease-agenda, because it's not showing on nodejs/Release#886