Suggested reviewers is another compelling use case. Automated mailing lists to reach all module members/owners is another.
Badges. Automated/shared review queues. Automatic CC of module members for reviews touching a module's files. And that's just my list. On Feb 11, 2014, at 11:25, Ehsan Akhgari <[email protected]> wrote: > On 2/11/2014, 12:42 PM, Gregory Szorc wrote: >> On 2/11/14, 9:01 AM, Ehsan Akhgari wrote: >>> On 2/11/2014, 5:27 AM, Reuben Morais wrote: >>>> On Feb 11, 2014, at 4:51, Byron Jones <[email protected]> wrote: >>>>> Kyle Huey wrote: >>>>>> We could copy the Chromium OWNERS file thing. >>>>> >>>>> that wouldn't work for modules which are not code (such as tree >>>>> sherifs, governance/policy, reps, ...). >>>> >>>> What does "check-in auditing" mean in the context of those modules? >>> >>> What does check-in auditing mean in the context of other modules which >>> have a code component (let's say in mozilla-central)? >> >> "Check-in auditing" means automated systems can scan pushed changesets >> for oddities and take action. e.g. "this change to dom/ was not reviewed >> by a DOM peer: I'm going to alert interested parties, including DOM >> module members." That may not be the best or most desirable example. But >> such scenarios are non-trivial without machine-readable module membership. > > OK, I suspect that the rules by which we operate in practice are much more > complicated than what a piece of software can enforce here. And in a lot of > cases they are subjective. For example, the build system module allows > modifications to Makefile.in/moz.build files that only modify the contents of > a variable list without a peer review. > > My point is, if this is the only reason why we want to have this data in a > machine consumable format, we should try to have a consensus that this is a > valuable goal. I am not sure such a consensus exists. > >> As for where that data lives, it doesn't matter as long as the >> consistency is guaranteed and the data can be reasonably trusted. >> >> For modules backed by code, I would prefer we define module membership >> in source trees (like OWNERS files) so a) it is easily versioned over >> time b) someone on a train without internet can query it. If we don't >> like the idea of fragmented module membership data, perhaps we could >> store module membership in a version controlled repository. We'd have a >> script in said repo that validated and converted whatever format we >> stored things in into JSON/XML/HTML/whatever. That facilitates offline >> access (anyone can clone that repo) and any automated agent could easily >> get their fingers on it. We could of course have that repo's contents >> exposed on https://www.mozilla.org/ somewhere. > > I personally don't care much about where this data lives either. I'd just > like to note that the OWNERS file format is probably suitable for expressing > some of our ownership information but not all (the build system comes to mind > as an example of something which won't be expressible in that format.) > > Also, maintaining this information in two places sounds worse to me than one > place, which is another point in favor of storing the information out of the > tree. > > Cheers, > Ehsan _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
