On Fri, Aug 15, 2025 at 10:21:41AM -0700, Otto Kekäläinen wrote:
Also, I doubt that reviewing MRs actually takes that much time.
Hello! I have some data, at least for myself from when I went freelance at the start of 2024 and started tracking most of the time I spend at a keyboard. The following excludes my time spent on Debusine, which has taken up the majority of my time since then but also isn't very representative of Debian work in general as it functions more like an upstream project in many ways.
In most cases any _individual_ thing I do in Debian doesn't take particularly long, though of course there are outliers. My mean time for reviewing an MR is about 25 minutes, but that's skewed towards some more complex cases; the median is about 11 minutes.
But MRs are only one of very many signals I get in my Debian development work. They're important, sure, but so are bug reports with patches attached, new upstream releases, RC bugs, contributors asking for help on IRC, and a whole slew of other things. MRs aren't anything like the only way I encounter new or inexperienced contributors, and they aren't consistently the pathway that it makes sense for me to prioritize.
Across all tasks that I do in Debian, my mean time spent is about 20 minutes and the median is 11 minutes, with 1257 data points. That means that on average reviewing an MR takes me a similar amount of time as other Debian-related tasks, and I have far more things to do than I have time to do them. At best I usually only manage somewhere around six hours a week on whatever I want in Debian, so I'm unlikely to manage to do much more than around 20 things a week in the best case. I try to focus that on whatever I think will be best overall: perhaps the thing most likely to unblock the greatest number of people, or the thing that really needs me rather than anyone else, or some metric along those lines.
This is a matter of my professional judgement, and the answer won't always be the same kind of thing. When we're coming up to a release, I tend to focus almost entirely on RC bugs. Near the start of a release cycle, my current judgement is that the most useful thing I can do is to try to reduce our backlog of new upstream releases. These days most of my time is spent on the Python team, where we currently have 803 packages that are out of date relative to upstream; to me that's a shockingly high number. All of those represent contributions that have been made and have not yet got into Debian, just as MRs do; I don't necessarily consider MRs to be a higher priority just because they're in Salsa. Because upstream Python packaging is such a complex landscape, some of them are tricky to integrate and need somebody quite experienced.
While in some cases those new upstream releases will come with regressions, overall I think it's likely that reducing the backlog will reduce the difficulty of backporting security patches later, reduce the risk of us encountering RC bugs due to changes in new Python versions that have been handled in those new upstream releases, and make things easier for other contributors (including new ones) because they don't need to deal with their dependencies being hideously outdated in order to get other changes made.
CI is useful for new upstream releases (whether that's Salsa CI, Debusine, the things that testing migration runs, or something else), but on the whole I tend not to find MRs particularly useful in those cases, either for contributors or reviewers. Because our branches generally include full upstream source, you end up wading through piles of upstream changes to see the few packaging changes, the workflow with the multiple branches that are involved is pretty awkward, and there are some mistakes that are more about the history structure than the diffs and so are pretty hard to spot in the web UI. Occasionally it can be made to work, but I've generally found MRs more confusing than helpful in these cases.
But all this is a judgement I've made for the best use of my own time, and other people will be making their own judgements for different reasons. I'm not out here lecturing others that they need to make the same judgements as I have or else they must not value new contributors properly. I don't think you should be either.
Have a good weekend, -- Colin Watson (he/him) [cjwat...@debian.org]
