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.
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.
_______________________________________________
governance mailing list
[email protected]
https://lists.mozilla.org/listinfo/governance
