Johan Corveleyn wrote on Thu, 22 Apr 2021 19:53 +00:00:
> On Thu, Apr 22, 2021 at 9:22 PM Daniel Shahaf <d...@daniel.shahaf.name> wrote:
> >
> > [ Forwarding from private@ with an addition between triple dashes and
> > some paragraphs omitted altogether. ]
> >
> > Methodology: In my dev@ mailbox, I looked at "Re: svn commit" threads
> > where the subject line contained "trunk" somewhere, filtered by date
> > (using, e.g., «~s 'Re: svn commit' !~<( ~s 'Re: svn commit' ) ~d '<730d'
> > ~s trunk» in Mutt¹). I then did a author histogram (the moral equivalent
> > of «SELECT author, COUNT(*) AS cnt FROM results_of_the_filter GROUP BY
> > author ORDER BY cnt»).
> >
> > With the date filter set to ">6 years ago", the histogram is:
> > .
> > 1, 1, 1, 1, 2, 3, 6, 7, 10, 12, 13, 13, 19, 27, 49, 58, 86
> > .
> > Top three: 28.1%, 19.0%, 16.0%.
> >
> > With the date filter set to "<2 years ago", the histogram is:
> > .
> > 1, 1, 1, 1, 1, 1, 1, 1, 4, 5, 30
> > .
> > Top three: 64%, 10.6%, 8.5%.
> >
> > Do we have a bus factor problem?
> >
> > ---
> >
> > I'm deliberately not posting the author identities part of the
> > histograms. It's public info (and I literally did just post
> > instructions for how to compute it, for reproducibility), but
> > no individual's contributions or contribution statistics are the point.
> >
> > The histogram is of the authors of commit review threads, not of
> > everyone who participated in such threads.
> >
> > ---
> >
> > Having few reviewers is problematic in various ways:
> >
> > - Bus factor
> >
> > - Single point of failure (cf. Linus' Law)
> >
> > - Possibility of zero reviews for some areas of the code
> >
> > - Review standards should be seen as community standards rather than
> > a reviewer's idiosyncrasies; cf. the point about new projects needing
> > at least two mentors ("parents"), rather than just one
> >
> > - [not an exhaustive list]
> >
> > Cheers,
> >
> > Daniel
> >
> > ¹ There may be a better way to express "first in a thread". I tried
> > «!~<(^)», but couldn't get it to work.
>
> Good point. But I believe we have many other areas where our bus
> factor is getting very low.
>
> - RM -- […]
>
> - Security issues: […]
>
> - Approving backports. […]
>
> - Signing releases: […]
>
>
> Perhaps the lack of review-activity for us as a CTR project is more
> critical, I don't know. Good observation in any case.
Note some of these issues are related: Approving backports amounts to
reviewing some specific commits carefully; work on security issues
involves some reviewing, some RMing, and some signing.
I'd be hesitant to say "more critical" because I'm not sure the
criticalities of these five areas are orderable, but historically,
I think we rely on commit reviews to catch certain classes of bugs: for
instance, cross-version compatibility (in the ABI, over the wire, in
on-disk formats) and FSFS concurrency guarantees are both core promises
that have little test coverage.
And, of course, there's any number of C gotchas and portability quirks
that our compilers don't warn on (in the default build configuration).
Cheers,
Daniel
