On 2/11/2014, 2:33 PM, Gregory Szorc wrote:
Suggested reviewers is another compelling use case.
Suggested reviewers may or may not benefit from this, since for some
modules not every peer will be the appropriate reviewer for every change
in that module in practice.
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.
Honestly I'm not quite sure why having that mailing list is useful, and
I don't really understand any of the others. But I guess this is kind
of a reply to this part of my comment ("if this is the only reason why
we want to have this data in a machine consumable format"), to which I
will reply, ok, point taken. You still did not reply to the rest of my
comment in the first paragraph.
Also, given the second paragraph of my response, do you think we need
anything more than a cleanup in the existing wiki and a simple parser to
extract the data out of it once we ensure that things such as email
addresses are properly formatted?
Cheers,
Ehsan
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
