Otto Kekäläinen <o...@debian.org> writes: > 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.
Yes, I know. I was being sloppy by not distinguishing between an MR and a branch. My point is that I push simple changes directly to main and more complicated changes that I want to test first to a branch so that I can run tests before merging. Sometimes I get this wrong and temporarily introduce a regression in main, and then I fix it. It's fine, the world doesn't end. The more simultaneous development is happening, the more likely I am to be cautious about avoiding build failures on main because I would inconvenience other people if I get it wrong. But even still, it's not the end of the world if I get it wrong occasionally. > 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. My point is not that I get this perfectly right. My point is that you are acting like Debian is a monorepo at a tech company where breaking the build causes a bunch of people hours of pain. Maybe this is true in a tiny handful of packaging repos, but it's *far* from a common situation. The consequences for guessing wrong on nearly all Debian packaging repositories are incredibly low. We should not be optimizing for this; we should be optimizing for ease of getting work done. You are advocating adding process for minimal gains. > 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. This would be an astonishingly effective way of making it not worth it to contribute to Debian at all. So no, I will not be doing this for every change. I'll do this when it feels warranted. > 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. I am *not* being social in most of the Debian work that I am doing. I'm just doing things that need to be done. Sure, sometimes I'm going to make mistakes, but no, I am not going to get code review for everything I do. Again, this is the kind of thing that is tedious and annoying and very much not fun, and if you want me to do that, you will have to pay me to do it. This is a very familiar argument. I've seen it happen many times. My firm opinion informed by a lot of years doing various types of software development is that both the "always get code review" and the "never get code review" crowds are wrong (and both of them are annoying in different ways). There are some projects that have both the (generally paid) resources to always do code review and the importance and complexity to warrant the effort (the Linux kernel, for instance). Most projects are not like that, but more to the point, it's simply not a realistic workload given the available resources for most projects. Even at my current day job, with a bunch of paid developers working together on a project, we are selective about what changes we ask for code review on because we have shit to get done, code reviews are tedious, waiting for code reviews destroys development momentum, and it's a waste of time and energy for most changes. For some important changes, sure, we absolutely do code review, and we do more code review when people are making changes to code they're unfamiliar with. But we certainly don't require code review for everything, or even most things. > What do you mean 'excessively'? I mean doing MRs, with or without code review, for every change just because you're worried that any change might introduce some mistake. This is excessive worrying and at least for me (and I suspect for a lot of other people) would just make contributing to Debian a chore. > Discussing changes with other people and doing reviews to maintain > quality is normal. Of course. I am not arguing against discussing changes with other people. I am arguing against forcing other people to discuss changes with other people when they don't think it's necessary. People can use their judgment about what things need review, particularly if they are experienced developers. > Why do you participate in open source if you worry about exposing your > work for public feedback? Oh, good grief. Once again, this is not even remotely what I said. If I didn't want to "expose my work for public feedback" I wouldn't publish it to a publicly accessible repository. This is not at all what we're talking about. I'm talking about introducing absurd levels of friction into every bit of Debian work that anyone does, something that would be spectacularly self-defeating. > 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. You have a completely absurd idea of how many development resources we have available. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
