On 20/04/2018 22:23, Kris Maglione wrote:
I can't remember the last time I saw a super-review request, but it's
still documented as a policy[1]. Is it still a thing? Do we want it to
still be a thing?
Not in the way it used to be. See
https://groups.google.com/forum/#!topic/mozilla.governance/HHU0h-44NDo .
The policy doc should have been retired / marked as historical. I don't
know how to go about making that happen... presumably talking to the
mozilla.org folks ?
My problem is essentially that, for a few areas of code, I'm the final
arbiter, or at least the main blocker, for a lot of large or critical
architectural or API changes. The upshot of that is that I get a lot of
review requests for patches in those areas, and most of the patches that
make it into my queue are large and/or complicated. This situation gets
exhausting after a while. And since people know that I tend to be busy,
they also avoid flagging me to review smaller patches, even when I
really *should* look at those patches (and therefore notice issues with
them only when I read code later).
For a lot of these patches, my opinion is only really critical for
certain architectural aspects, or implementation aspects at a few
critical points. There are other reviewers who are perfectly qualified
to do a more detailed review of the specifics of the patch, and have
more spare cycles to devote to it. Essentially, what's needed from me in
these cases is a super-review, which I can do fairly easily, but instead
I become a bottleneck for the code review as well.
So, for the areas where I have this responsibility, I'd like to
institute a policy that certain types of changes need a final
super-review from me, but should get a detailed code review from another
qualified reviewer when that makes sense.
Does anyone have any objection to this plan? Or any suggestions for
another way to go about it?
I'd like to ask 2 questions:
- which specific areas of code will this cover? The other examples cited
in this thread (webidl reviews; old-style super-review) have (had) clear
definitions of the boundaries of this type of oversight, and esp. the
former is enforced via commit/push hooks. Do you intend to do the same here?
- what are we/you doing to fix the bus factor here? Again, both of the
webidl and previous sr requirements have (had) groups of people
associated with them, so things weren't blocked if 1 person went on
holiday, left the project, or was otherwise not available. I think we
need to avoid ending up in a situation where you can't take holidays or
where we're completely stuffed if you ever decide to leave. :-)
Especially to the latter of these 2 points, I would feel more
comfortable with this arrangement if there was more than 1 person around
to exercise this type of oversight, even if you were the
"owner"/buck-stopper and other(s) were "peers" (in the module governance
sense).
~ Gijs
-Kris
[1]: https://www.mozilla.org/en-US/about/governance/policies/reviewers/
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
