[Request for Comments] TEAM file proposal

[Shruthi]

There is, currently, no maintained information about which team (mailing list) owns code directories and which Monorail component (crbug component:<>) it maps to. This proposal is to create a TEAM file per directory that contains this information. Motivation/use cases are in the document, please comment/discuss/review there by end of week.

Thanks,
Shruthi

[Shruthi]

Thank you all for the lively discussions on the document. This has been extremely helpful! There seems to be broad agreement that we need this, and the devil is in the details. I made one major change (moved the information to OWNERS file) and also addressed some of the common questions/comments in the proposal. Please take another look and leave comments.

[Jason Robbins]

This looks good to me.  This mapping should be very useful and I think that having both the TEAM and COMPONENT directives avoids further mixing of those concepts.   In your example I am pleased to see that the syntax of the COMPONENT directive value makes it visually apparent that this is an issue tracker component name when it is more than one level deep, which will be the most common case.

Thanks,

jason!

[Ojan Vafai]

Do we still have it so "set noparent" doesn't apply to TEAM and COMPONENT? I think the answer should be yes.

[Peter Kasting]

On Fri, Oct 21, 2016 at 2:14 PM, Ojan Vafai <oj...@chromium.org> wrote:

Do we still have it so "set noparent" doesn't apply to TEAM and COMPONENT? I think the answer should be yes.

Maybe the way to make that clearest would be to list TEAM and COMPONENT first?

#TEAM: f...@google.com

#COMPONENT: UI>Blah

set noparent

x...@pdq.now

b...@bob.bob

PK 

[Ojan Vafai]

That does seem somewhat better. 

[Skycn Cn]

Dear all,

Pls remove my email out of this group! I don't know what everybody say! 

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[Peter Kasting]

->chromium-dev to bcc

On Fri, Oct 21, 2016 at 8:29 PM, Skycn Cn <skyc...@gmail.com> wrote:

Pls remove my email out of this group! I don't know what everybody say! 

You weren't being directly emailed, so you're getting mail because you're subscribed to the chromium-dev list.  To copy and paste the directions that appear below every mail in this list:

"You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

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

PK

[Chee Cherng Ho]

在 2016年10月12日星期三 UTC+8上午5:35:44，Shruthi写道：

[Shruthi Sreekanta]

On Fri, Oct 21, 2016 at 2:28 PM Ojan Vafai <oj...@chromium.org> wrote:

That does seem somewhat better. 

On Fri, Oct 21, 2016 at 2:23 PM Peter Kasting <pkas...@chromium.org> wrote:

On Fri, Oct 21, 2016 at 2:14 PM, Ojan Vafai <oj...@chromium.org> wrote:

Do we still have it so "set noparent" doesn't apply to TEAM and COMPONENT? I think the answer should be yes.

I added this explicitly to the doc that "set noparent" does not apply to TEAM and COMPONENT. 

[Vincent Scheib]

I'm still concerned about having both TEAM and COMPONENT. Essentially, data duplication.

I agree that we should have a mapping from COMPONENT to TEAM emails, but I think that should not exist in OWNERS files. Adding COMPONENT should be sufficient to describe the relationship of code -> component -> team. Having multiple OWNERS files with potentially disjoint pairs of TEAM:COMPONENT seems unwise.

Further, monorail would benefit from a mapping of component to team, and both of these systems should use the same single data source.

--

[Shruthi Sreekanta]

That is a fair concern. My hope is that this will also help us sort through any such components with overlapping teams and clarify the ownership. The intent here is to map code to owner teams. For now, let us keep this information in the code directory (we can do some automated auditing if this turns out to be a common issue). If Monorail enables a way to store the component->team mapping, then we can definitely talk about avoiding data duplication at that point by using tooling to ensure the data stays consistent.

[Shruthi Sreekanta]

Thank you all for your comments on this proposal! The document is now final. Please update the OWNERS files for any directories that your team owns. If there is a need for a new component, please file a request using this template. 

A request: please take a few minutes to also review the list of reviewers and update as appropriate (if you don't want to remove names, you could comment out and move to the end any inactive ex-reviewers). If you are listed as a reviewer on directories that you don't feel comfortable reviewing anymore (you haven't worked on this stuff in a very long time, perhaps?), please remove yourself from the list. 

I will be back with an update and plans (depending on the state of coverage of directories) after the holiday season.

Thanks,

Shruthi

[Charles Harrison]

Can the document please be made public to the web? We have OWNERS files with non-google owners (with non chromium.org addresses) that should be aware of these changes.

---

You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

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

[Vincent Scheib]

Let's not create the mess to clean up. We had a long group conversation Tuesday where I thought we had consensus that we should keep to a single definition for component to team mapping in a root file in the repository. We discussed the value of this before we call for teams to create the new data definitions. We discussed that monorail does not need to store the mapping, it will be held in the source and monorail may injest it from there.

[Shruthi Sreekanta]

Moved the doc to a public version (the earlier one was open to a...@chromium.org by default, and to anybody else who requested). Please shoot me a separate email if you have trouble viewing it.

We really want both component AND team in the OWNERS files (some of the motivations are in the Overview section of the doc), rather than create a two-step process to get from a directory to a team. With that in mind, there is NO CHANGE to the proposal. If there are any specific questions about this, please do comment on the doc.

Your concern was about keeping the mapping from component to team consistent across directories. The mappings will be made available in a single source that any tools/trackers can link into, and there will also be a presubmit to ensure that a component does not map to different teams in different directories. If you are interested in the design of these, please comment on the bugs.

Thanks,

Shruthi

[Vincent Scheib]

Thanks, the presubmit and aggregation of mappings address my concerns well.