Re: Please check open Merge Requests before your next upload
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]
Reply to: