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 -- after Julian, only Stefan volunteered. We seem to depend a lot
on the available volunteer time of just a single person, for whether
or not a release will be made and in what timeframe.
- Security issues: sometimes they linger for a long time because ...
well they just lie there. Sometimes some of us perform a couple of
steps, but then we stall again waiting for reviewers, other people to
chime in, etc. This can take weeks or months of "standstill", and I'm
guessing some of the people pushing the cart often feel "I'll give a
little push because it's been stuck for too long, and it's getting
embarrasing -- otherwise it might be lying here for years"
- Approving backports. Last time we really had to scrape the very few
resources we have left to get anything backported (I used to almost
never spend any effort on reviewing backports -- there were plenty of
other more experienced devs around -- but this time I more or less
felt "forced" to go that extra mile).
- Signing releases: last couple of years I'm the only one to build /
test / sign for Windows. I have often wondered how long one of our
releases would be stuck if I were to disappear / drop my laptop.
Perhaps the lack of review-activity for us as a CTR project is more
critical, I don't know. Good observation in any case.
--
Johan
