Please remove this person from the mailing list. He has cancer is no longer
able to make cognitive decisions regarding this discussion.
Thank-you,
Caretaker of Luke Perkins
-----Original Message-----
From: Daniel Shahaf <d...@daniel.shahaf.name>
Sent: Thursday, April 22, 2021 5:11 PM
To: Johan Corveleyn <jcor...@gmail.com>
Cc: Subversion Development <dev@subversion.apache.org>
Subject: Re: Commit reviews' author statistics: bus factor issue?
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
