Add an OWNERS file for src\content by moving the owners that were there for the top level directori…

Add an OWNERS file for src\content by moving the owners that were there for the top level directories within. I've removed them all from the subdirectories. Also removed the "set noparent" in subdirectories and just put one in src/content/OWNERS for now. I also added brettw/darin for src/chrome/OWNERS.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=126522

[Dirk Pranke, 2012-03-13 01:42:12]

technically, the patch lgtm.

stylistically, I'm not sure you really want to make these changes. It might be a
good idea to keep some redundancy in the lower directories, since someone
looking for reviewers/owners is going to look there first.

For example, brettw is clearly a great reviewer for content_ppapi and almost
certainly knows it better than ben (or any of the rest of the top-level OWNERS).

However, if you make this change, someone who doesn't know the code won't have
any clue that a change in content_ppapi should probably go to brett and not ben,
and piman might end up getting all of the CLs ...

[jam, 2012-03-13 02:19:21]

On 2012/03/13 01:42:12, Dirk Pranke wrote:
> technically, the patch lgtm.
> 
> stylistically, I'm not sure you really want to make these changes. It might be
a
> good idea to keep some redundancy in the lower directories, since someone
> looking for reviewers/owners is going to look there first.
> 
> For example, brettw is clearly a great reviewer for content_ppapi and almost
> certainly knows it better than ben (or any of the rest of the top-level
OWNERS).
> 
> However, if you make this change, someone who doesn't know the code won't have
> any clue that a change in content_ppapi should probably go to brett and not
ben,
> and piman might end up getting all of the CLs ...

In google3, owners don't percolate down to solve this problem. Instead, it's the
developer's job to look through the file history to see who's been reviewing
changes.

One thing that might help, which is in google3 but we don't have, is that the
tools add a "R=" line at commit time based on who the reviewers were.

[Peter Kasting, 2012-03-13 02:25:16]

FWIW, as someone who does infrequent work in content/, I'm with Dirk -- I think
the OWNERS are vastly clearer as they are then how you're changing them.  When
making changes, I try to look in the OWNERS file for the specific subdirectory
I'm in, if there is one.  With these changes, I'd never send changes in these
subdirectories to any of the people you're removing except by chance if I did a
big refactoring.

I really, really, really think you should reconsider and just make this patch
remove set noparent.

(I'm also kind of confused by the "owners don't percolate down" statement. 
Doesn't that mean that I shouldn't assume someone in content/OWNERS is a good
fit for content/ppapi_plugin/OWNERS?  That seems like precisely what I said
above, which is an argument against this patch as it stands.)

[joth, 2012-10-20 19:07:31]

https://chromiumcodereview.appspot.com/9695028/diff/1/content/public/OWNERS
File content/public/OWNERS (right):

https://chromiumcodereview.appspot.com/9695028/diff/1/content/public/OWNERS#n...
content/public/OWNERS:4: # For other reviews (modifying existing APIs), prefer
avi@ or joi@.
this comment implies all content/public changes still must go through either
joi, jam or avi. Any reason not to  enforce that by keeping the set noparent?

https://chromiumcodereview.appspot.com/9695028/diff/1/content/public/OWNERS#n...
content/public/OWNERS:10: # up, IM one of the owners above.
this comment is probably obsolete now?