From: cjwatson@debian.org 
  
 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)                              [cjwatson@debian.org] 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)