Proposal to elect new release rc--2024-08-29_01-30

Thanks for this release DFINITY!

:point_up:
I wanted to make sure that I understood what was happening here, as it’s unusual and really not obvious. I filtered my git client to show only the two relevant branches to cut down on all the noise, and then produced this modified screenshot to illustrate the situation (highlighting the ‘merge base’ commit that’s referred to in the proposal summary, along with the previous release and this proposal’s release).

You can see that the previous release is left out on a limb and is never merged (effectively discarding that commit with respect to this release). The discarded commit isn’t actually a GuestOS commit (what a distraction :pensive:).

Just a final comment on the matter - the commit is actually cherry picked back into this release branch (so actually the changes aren’t really discarded after all, they are included in this release… :neutral_face:). Not only that but the commit includes a few subtle additional changes this time around.

The point I’m emphasising is that the IC repo uses git in an unconventional way that makes it very difficult to get a handle on what’s going on. There’s no reason the original commit couldn’t have been merged into the new release branch, and an additional commit made for the updated changes. This approach would have:

I’d expect these to be goals for any Web3 project that’s serious about governance decentralisation. Is there any chance of introducing best practice policy to improve matters here @basvandijk?