Re: Help wanted: volunteer yourselves in .github/CODEOWNERS

On Sun, May 30, 2021 at 8:17 PM Kubilay Kocak <koobs@freebsd.org> wrote:

> On 31/05/2021 9:13 am, Alan Somers wrote:
> > Strangers are submitting pull requests to our Github mirror, but we
> rarely
> > pay attention.  I just added a .github/CODEOWNERS file to our repo to
> > automatically assign reviewers to PRs.  I based it off of the contents of
> > the current MAINTAINERS file.  But it's incomplete.  Please add yourself
> if:
> >
> > * You don't have a github account associated with your FreeBSD email
> > address.  I'm talking to you, adrian@, macklem@, and rrs@ .
> > * You are part of a team, like secteam@ or re@ .  You'll have to create
> the
> > team at https://github.com/orgs/freebsd/teams then you can add it to the
> > list.
> > * You previously signed up for Phabricator notifications with Herald, but
> > didn't sign up in MAINTAINERS.  I can't see everybody's Phabricator
> > assignments.
> > * You never signed up in MAINTAINERS before, but you really ought to
> > because you care deeply about some particular subsystem.
> >
> > -Alan
> >
>
> Thanks for this Alan.
>
> Bugmeister is (and has been for a while) also keen to finally solve the
> problem of better getting the right eyes on patches submitted to
> Bugzilla for particular code areas, which complements other areas of
> improvements in issue management, such as more and clearer components in
> Bugzilla for people to use.
>
> Ports has an explicit MAINTAINER line we use to automatically
> auto-assign and CC issues, it would be great to use CODEOWNERS for this,
> along with appropriate consistently declared MAINTAINER lines in
> specific component directories and/or Makefiles.
>
> I think this is a good time to raise the difficult question/issue of
> policy/guidelines around code maintainership and responsibilities around
> that, including:
>
> - Having one or more maintainers of tree areas/components
> - Maintainer review, approval and timeouts
> - Issue triage/management
>

Before I start, I'd like to note what we do today isn't working. We have a
lot of
intake points and it's hard to find things for developers. We need to do
something
different to help tame the chaos.

The src tree and the ports tree are somewhat different in terms of all
these issues.
Some parts of the tree require proper oversight by a small group of experts
(regardless
of timeout), while other parts of the tree need less oversight. Some parts
of the tree
you can get a good notion of who should get reports of bugs based on who
has made
recent changes (though API sweeps can skew the results). Other parts of the
tree the
changes are far enough in the past to be a poor judge.

I suspect that a combination of what we've done in the past, coupled with
some shifts
with roles as the project modernizes and liberalizes. Whatever we put into
place
will need to grow with us.

Finally, we've had a poor history of maintaining long lists of maintainers,
so I suspect
we'll need to have some kind of automation involved to keep things fresh
enough to
be useful.

Warner