Adding a real OWNERS file for tools/

58 views
Skip to first unread message

Nico Weber

unread,
Nov 10, 2015, 1:18:41 AM11/10/15
to Chromium-dev, Daniel Cheng
Hi,

src/tools/ is supposed to house many small tools that people write, so that useful tools get checked in instead of living in your home directory. Hence, tools/OWNERS is *.

However, some things in tools/ are kind of important, and hence some of the tools subfolders have OWNERS files that contain "set noparent". noparent generally shouldn't be used (it makes global refactorings harder, and needing it usually just exposes a bad directory structure), so I'd like to propose changing tools/OWNERS to not be *.

Instead, I propose it should contain something like

"""
You can add new small tools to this directory at your desire, feel free
to owners-TBR new folders (assuming you have a regular review already,
of course). Include an OWNERS file with at least two people for your new
folder.
If you're changing existing tools, have your change reviewed by the
OWNERS of the existing tool.
"""

Is anyone opposed to this?

Also, if you have a tool in src/tools, now would be a great time to add an OWNERS file for it :-)

Nico

藤澤和宏

unread,
Nov 10, 2015, 2:24:46 AM11/10/15
to Chromium-dev, tha...@chromium.org, Daniel Cheng

2015年11月10日(火) 15:17 Nico Weber <tha...@chromium.org>:
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

Dirk Pranke

unread,
Nov 10, 2015, 12:27:57 PM11/10/15
to Nico Weber, Chromium-dev, Daniel Cheng
On Mon, Nov 9, 2015 at 10:17 PM, Nico Weber <tha...@chromium.org> wrote:
Hi,

src/tools/ is supposed to house many small tools that people write, so that useful tools get checked in instead of living in your home directory. Hence, tools/OWNERS is *.

However, some things in tools/ are kind of important, and hence some of the tools subfolders have OWNERS files that contain "set noparent". noparent generally shouldn't be used (it makes global refactorings harder, and needing it usually just exposes a bad directory structure), so I'd like to propose changing tools/OWNERS to not be *.

Instead, I propose it should contain something like

"""
You can add new small tools to this directory at your desire, feel free
to owners-TBR new folders (assuming you have a regular review already,
of course). Include an OWNERS file with at least two people for your new
folder.
If you're changing existing tools, have your change reviewed by the
OWNERS of the existing tool.
"""

So the new OWNERS file would contain no owners, and we'd TBR one of the top-level
owners?

-- Dirk

Scott Hess

unread,
Nov 10, 2015, 1:02:46 PM11/10/15
to Nico Weber, Chromium-dev, Daniel Cheng
What about tools/experimental (or spiritual kin), with a rule that nothing in tools/ can depend on things in experimental/ ?

-scott


On Mon, Nov 9, 2015 at 10:17 PM, Nico Weber <tha...@chromium.org> wrote:

--

Nico Weber

unread,
Nov 10, 2015, 1:55:19 PM11/10/15
to Dirk Pranke, Chromium-dev, Daniel Cheng
Yes – that way putting new things in tools doesn't become harder. (We could also list some name in tools/OWNERS who's TBR'd instead, probably doesn't make a huge difference either way.) I guess it should also have per-file entries for the .py files directly in tools/.

> What about tools/experimental (or spiritual kin), with a rule that nothing in tools/ can depend on things in experimental/ ?

I think it's nice that we have a place where people can put their tools and if something catches on then it just gets more usage. It has worked pretty well so far, so I don't see a need to change how the directory is organized – I just want to make it so that we don't need "set noparent" in a couple of OWNERS files in subdirectories of tools.

Dirk Pranke

unread,
Nov 10, 2015, 3:07:50 PM11/10/15
to Nico Weber, Chromium-dev, Daniel Cheng
On Tue, Nov 10, 2015 at 10:54 AM, Nico Weber <tha...@chromium.org> wrote:
On Tue, Nov 10, 2015 at 9:26 AM, Dirk Pranke <dpr...@chromium.org> wrote:
On Mon, Nov 9, 2015 at 10:17 PM, Nico Weber <tha...@chromium.org> wrote:
Hi,

src/tools/ is supposed to house many small tools that people write, so that useful tools get checked in instead of living in your home directory. Hence, tools/OWNERS is *.

However, some things in tools/ are kind of important, and hence some of the tools subfolders have OWNERS files that contain "set noparent". noparent generally shouldn't be used (it makes global refactorings harder, and needing it usually just exposes a bad directory structure), so I'd like to propose changing tools/OWNERS to not be *.

Instead, I propose it should contain something like

"""
You can add new small tools to this directory at your desire, feel free
to owners-TBR new folders (assuming you have a regular review already,
of course). Include an OWNERS file with at least two people for your new
folder.
If you're changing existing tools, have your change reviewed by the
OWNERS of the existing tool.
"""

So the new OWNERS file would contain no owners, and we'd TBR one of the top-level
owners?

Yes – that way putting new things in tools doesn't become harder. (We could also list some name in tools/OWNERS who's TBR'd instead, probably doesn't make a huge difference either way.) I guess it should also have per-file entries for the .py files directly in tools/.

I would suggest we have some additional names so the top-level owners don't get too many TBRs. I'm not volunteering at the moment, though :).

I do think we should have owners for the individual files, though.
 

> What about tools/experimental (or spiritual kin), with a rule that nothing in tools/ can depend on things in experimental/ ?

I think it's nice that we have a place where people can put their tools and if something catches on then it just gets more usage. It has worked pretty well so far, so I don't see a need to change how the directory is organized – I just want to make it so that we don't need "set noparent" in a couple of OWNERS files in subdirectories of tools.

I don't think we need to go so far as to have an experimental/ subdir either.

-- Dirk

Nico Weber

unread,
Nov 12, 2015, 2:52:24 PM11/12/15
to Dirk Pranke, Chromium-dev, Daniel Cheng
On Tue, Nov 10, 2015 at 12:05 PM, Dirk Pranke <dpr...@chromium.org> wrote:


On Tue, Nov 10, 2015 at 10:54 AM, Nico Weber <tha...@chromium.org> wrote:
On Tue, Nov 10, 2015 at 9:26 AM, Dirk Pranke <dpr...@chromium.org> wrote:
On Mon, Nov 9, 2015 at 10:17 PM, Nico Weber <tha...@chromium.org> wrote:
Hi,

src/tools/ is supposed to house many small tools that people write, so that useful tools get checked in instead of living in your home directory. Hence, tools/OWNERS is *.

However, some things in tools/ are kind of important, and hence some of the tools subfolders have OWNERS files that contain "set noparent". noparent generally shouldn't be used (it makes global refactorings harder, and needing it usually just exposes a bad directory structure), so I'd like to propose changing tools/OWNERS to not be *.

Instead, I propose it should contain something like

"""
You can add new small tools to this directory at your desire, feel free
to owners-TBR new folders (assuming you have a regular review already,
of course). Include an OWNERS file with at least two people for your new
folder.
If you're changing existing tools, have your change reviewed by the
OWNERS of the existing tool.
"""

So the new OWNERS file would contain no owners, and we'd TBR one of the top-level
owners?

Yes – that way putting new things in tools doesn't become harder. (We could also list some name in tools/OWNERS who's TBR'd instead, probably doesn't make a huge difference either way.) I guess it should also have per-file entries for the .py files directly in tools/.

I would suggest we have some additional names so the top-level owners don't get too many TBRs. I'm not volunteering at the moment, though :).

I do think we should have owners for the individual files, though.

Ok, there's now a CL here with these suggestions: https://codereview.chromium.org/1437683006/
Reply all
Reply to author
Forward
0 new messages