On 1/29/13 7:42 AM, Mike Connor wrote:
(I'm not sure why followup was intended for dev-identity,
That was the guidance I got from Brendan, though it's certainly possible
I goofed that one up. cc'ing both for this.
* Scope
A long time ago we discussed a similarly broad module for services,
and it was argued quite convincingly that we should not attempt to
create a module stretching across multiple client and server products
with diverse codebases. The primary reason is that the skill set and
domain expertise to write highly scalable and available services
differs in significant ways from the ability to write robust and
performant Firefox client code. I'm not suggesting one person cannot
do both, but that most people will do one or the other. I would
prefer to see a separation of concerns here, in order to foster
stronger leadership on both client and server code. The right size
of a module, in my experience, is where the owners and peers have a
strong understanding of the module as a whole, and I'm not convinced
this would meet that criteria.
I hear this concern, and I can't speak to the historical issue.
However, I can say that we did this combination of client and server
code very successfully with BrowserID/Persona, and that I think it's
just as important (if not more) to design the service as a coherent
whole. The module-overlap double-approval should cover the concerns you
raise, in my opinion.
* Experience working on Firefox
In general, it is expected that the owners (and their peers) of any
code module expected to ship in Firefox have significant experience
and knowledge of the Mozilla codebase as a whole.
I think we have shown, with folks like Jed (and to some extent me), that
we can ramp up and learn about the client-side code and deliver very
high quality code that ships. With the double-approval and the
double-module-owner design sessions, I believe we'll have an extra level
of safety against this.
Let's remember that there is a large service component to this. Given my
first argument - that we should design this service as a whole rather
than in pieces - we are bound to have more expertise on one side than on
the other. With help from existing client-side module owners, I think
we're balancing things out pretty well.
-Ben
_______________________________________________
governance mailing list
[email protected]
https://lists.mozilla.org/listinfo/governance
