Discussion:
Help wanted: volunteer yourselves in .github/CODEOWNERS
Alan Somers
2021-05-30 23:13:13 UTC
Permalink
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
Kubilay Kocak
2021-05-31 02:16:48 UTC
Permalink
Post by Alan Somers
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
* You don't have a github account associated with your FreeBSD email
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
Warner Losh
2021-05-31 03:42:15 UTC
Permalink
Post by Alan Somers
Post by Alan Somers
Strangers are submitting pull requests to our Github mirror, but we
rarely
Post by Alan Somers
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
* You don't have a github account associated with your FreeBSD email
the
Post by Alan Somers
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
- 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
Poul-Henning Kamp
2021-05-31 05:25:03 UTC
Permalink
--------
Strangers are submitting pull requests to our Github mirror, [...]
The are not "strangers".

They are enthusiastic FreeBSD users and potential future committers,
and should be treated as such!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Mark Linimon
2021-05-31 05:28:08 UTC
Permalink
Post by Poul-Henning Kamp
They are enthusiastic FreeBSD users and potential future committers,
and should be treated as such!
The same goes for non-committers and phabricator, IMHO.

mcl

Loading...