Proposal to elect new release rc--2024-07-25_21-03

[Lorimer]

Thanks @Luka! Looks like there’s a good chance that logic is the issue. I raised questions about that specific line a few weeks ago

@Lorimer

But then this decision is overridden if the file(s) are not considered to be owned by the replica teams. It seems like the important thing should be that a file that constitutes a replica dependency has changed (regardless of who is considered to be the owner of that file)

(EXCLUDED_TEAMS has since been renamed to NON_REPLICA_TEAMS)

@Luka

we wouldn’t have linear history on master in that case

The master branch would describe the reality of the situation. Isn’t that better? There are already non-linearities in the deployment history. Can I ask what problems representing this on the master branch would cause? (at least in cases where there’s genuinely no divergence)

@Luka

i’m looking into some way to share all the list of commits that modify guestos. for release notes, we’d still want to make it even less than that just so we don’t have commits that don’t contribute much.

This sounds promising, except that release notes will intentionally (as opposed to accidentally) exclude commits that modify GuestOS. Why would DFINITY want to do this? In some ways this could be seen as worse. It certainly seems like a bad precedent to set for such critical proposals. I think the principle here is the most important thing (which is why I’ll reject this proposal, in peaceful protest of the obscured changes - I suspect there are more).

@Luka

i’ll try to improve this logic a bit. we also plan on improving package dependencies for guestos so we can be less aggressive on these heuristics that exclude commits from release notes,

Thanks Luka. Do you have any thoughts about the deployment target commit message convention that we discussed with @sat last week in our CodeGov meeting. My impression was that this was being investigated.