Proposal to elect new release rc--2024-08-21_15-36

[Lorimer]

Thanks for this release @DRE-Team!

@DRE-Team

4897fd255 Interface(PocketIC): subnet read state requests (#968)
…
234ca3809 Interface(PocketIC): do not use no_op_logger and MetricsRegistry::default in PocketIC (#965)

Presumably these were picked up as GuestOS changes due to the changes to rs/http_endpoints/public/src/lib.rs and other dependencies? This is the same situation as mentioned last week, where it was strongly agreed that this is a problem.

@Luka

i strongly agree in principle that such changes should be split

I’m still not clear on what the plan is for solving this:

@Lorimer

Thanks @Luka. All sounds good, but in this instance I’m just talking about how to encourage appropriate splitting of commits (to avoid fat commits that add unnecessary noise to proposal change logs).

What I’m really saying here is how do we encourage developers to think about this when they’re committing? Once they’ve committed, it’s committed…

This is one of the reasons I think that IC engineers should be asked to label their commits with the affected deployment targets (making them mindful of the change logs their commit will show up in, and then consider whether that would be appropriate).

@Luka

it’s not that it would be hard to change this or that it would disrupt developer’s workflows so much. i just doubt it would be valuable enough. i think it would be worse than what we have now because it’s non-enforceable

I think there must be a misunderstanding, I’m not talking about taking anything away (I can’t see how it would be ‘worse than what we have now’). If they don’t do this having been asked, that’s a separate issue. Anticipation that they won’t do this despite being asked isn’t a good reason not to just ask… (they may not be aware that this is an issue - one that you strongly agree with).