Hi, (I didn't get Russ original email, so mostly replying to it via this)
> Am Thu, Aug 14, 2025 at 12:02:19PM -0700 schrieb Russ Allbery: > > For the record, I will not use MRs routinely for my own packages. I do not > > like this workflow for my own changes, and I am going to continue to push > > directly to the primary branch unless I need an MR for some reason (such > > as triggering checks of a change that I think might fail checks). First of all you don't need a MR to trigger CI. You can just push your branch and you will get an email if CI failed. Secondly, you might be super intelligent and never make mistakes, or know in advance if you are about to make a mistake and only run CI on those commits as you stated, but for the average programmer the purpose of CI is to validate that everything indeed works even when there was no suspicion that something might be off, and CI should be used to gatekeep all commits. > > I don't care if occasional mistakes get into my repositories. Sure, you can do whatever you want with *your* repositories. But you should not have that attitude for *our* shared repositories. The people who suffer for your mistakes will care, and the person who needs to suck it up and do the ungrateful work of fixing up after another person's careless mistake will feel demotivated. I think it is way smoother to just post MRs, wait a few days, and get the changes in with lower chances of unintentionally breaking something. It is also more social to show what you are doing and get feedback, than to just do it and expect somebody else to find out what was wrong and go and clean up afterwards. > > Worrying > > about such things excessively is paralyzing and demoralizing and is a > > recipe for doing even less volunteer work. What do you mean 'excessively'? There are already a bunch of MRs at https://salsa.debian.org/debian/devscripts/-/merge_requests and thousands more across Salsa in various projects. Discussing changes with other people and doing reviews to maintain quality is normal. The 'given enough eyeballs' is part of the ethos why we think and hope open will eventually win over closed. Why do you participate in open source if you worry about exposing your work for public feedback? > Very same here and nearly all teams I'm working in share this habit. We > usually have to few potential reviewers and development would be heavily > stalled by waiting for reviews. I don't think the solution is to stop doing code reviews, but instead to try to remind people to look at open MRs more often and to discuss the topic of MRs inside the team. It is not really fulfilling the true meaning of a team if people mostly work on their own without reviews of cross-pollinating knowledge across packages and people in the team?
