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
