On 07/10/2017 06:03 AM, Rich Bowen wrote:
On 07/07/2017 09:39 AM, Shane Curcuru wrote:
I think "CODEOWNERS" is too strong a term; they should have been more
descriptive with CODEREVIEWERS or the like, since these aren't
necessarily owners of a file or project. That might be useful feedback
for github, but since they've already rolled it out, I doubt they'd
change it.
Perhaps change it to COOKIELICKER instead?
Every project I've worked in where someone "owned" a particular
feature/file/method/document, that thing has ended up either getting
neglected (because nobody else was willing to touch it) or caused fights
(because someone else *was* willing to touch it).
I think Shane's point is that the feature doesn't actually imply
ownership; it implies required review. That can be twisted into
something negative, like code silos and cookie licking, or it can be
used to automate what some Apache projects are already doing. I think
it's a nice concept, if poorly named.
Has anyone actually tried to use the functionality? From their
documentation on the feature, you don't have to put a single person as
the reviewer -- you can specify a GitHub group. So, to give a concrete
example, httpd could protect their 2.4.x backport branch with the group
of httpd committers, protect the docs/ directory with httpd-docs
committers, and put security-critical files on review with the security
team. The automation means that it's harder for things to slip through
the cracks: if that "documentation-only" pull request suddenly requires
a security review, something is *wrong*.
Can it be abused? Certainly. Will it be abused? Probably. Does that mean
it sucks? Nah.
--Jacob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
