On 31/10/2025 21:59, Jeremy Stanley wrote:
On 2025-10-31 12:48:13 -0700 (-0700), Jay Faulkner wrote: [...]
To be clear: the safeguards shouldn't be seen as a lack of trust, but maybe instead as an acknowledgement that structural controls hold value even if there's no reason to assume mistrust. [...]
One way to approach this is as a safety net for the benefit of these new additions. People who are just starting out as core reviewers can easily be intimidated by the fear of approving something that causes a problem, and then being the one who's blamed for that decision. The new model you've chosen for Ironic gives them room to voice their opinions without feeling like they're at risk of letting you down for doing so.
honestly my approach to that when ever i have given someone sudo rights or admin on something has been very simple. i am trusting you with the power to improve things and break things, if you break things we will fix it together and learn form the experience. In otherword if you do end up approving something that breaks something i would hope that you will help us fix it when we realsise a mistake happened. Out side of the final FF/RC period its unlikely that a merge patch is going ot break production. yes we try to keep master shipable to production but we can generally revert such a change quickly before it impact ops. the other things to note is that most project expect 2 reviewers for most things and in the proposed model the approves group is still the group with the +w rights so there is still a mentoring/oversight group that will hopefully catch any problematic patch before it get that far. im not going to comment on any of the specific number of review per week as that really depend on the review and velocity of the project but i don't think the idea is bad overall. the other thing i wanted to mention is there is another path to core that is less commonly taken, become a stable core first. that allows the person to demonstrate there good judgement by applying the stable policy and learn the code-base while also doing valuable work by maintaining the stable branches. for operators in particular that allows them to help shepherd the bug-fixes that will impact there production deployments into release closer to what they run. its also a little less daunting as there isn't the same pressure to know how all the code base should work, the design and direction has been already been assessed by the core team and as a stable core your focused more on the correctness of the backport and that it follow stable policy. so the pressure associated with the fear of approving something that causes a problem should be lessened as a result. regards sean