>> Although we've seen bad bugs (and bad memory bugs in particular) come >> from coders of all levels of experience, I personally am not at all >> comfortable with the idea of inexperienced Firefox front-end coders >> having review power in a module we intend to ship in Firefox. > > That's not the situation we have. Jed Parsons and I have both landed a good > bit of code (in BrowserID module) for FX Desktop and FXOS+Gaia. So we have > experience. We're not the world's experts, but we also know our limitations > and have always consulted with other teams starting with initial designs > (e.g. Dolske). > > Remember that an equally (if not more) important aspect of this module is > the service integration piece, which is where we *are* indeed experts.
Indeed, and nobody is arguing that you shouldn't have full review powers over the service parts of this project. The argument is that Firefox peers should at least sign off on this plan to create a new Firefox module composed of people who, as I understand, have not landed any code in desktop Firefox which is currently enabled. Also note that two of the proposed module peers apparently do not have any experience hacking on Firefox or Gecko at all. (At least, I don't see any commits in m-c with the names 'Mayo' or 'Hilaiel'.) I would object strongly to making someone a peer of a new Gecko module affecting desktop Firefox if their only experience on the desktop was hacking on a module which was currently disabled, and of course we wouldn't even consider giving someone review power in Gecko if they had no experience there. But I can't speak for the Firefox folks, which is why I'm asking that you find someone who is willing to vouch for you. >> If one or more existing Firefox peers is willing to personally accept >> responsibility for this module, I'd be OK with this proposal. Do you >> think that's a fair burden to meet? > > Given the above, and given the module's explicit callout that nay overlap > will require full cooperation of other module owners, I don't think that's a > fair burden to meet, if only because everyone is already incredibly > over-committed. I don't think that the "full cooperation of the relevant module owners" criterion is sufficient. If your intent is to get relevant module owners to review your code, then just create a separate module for the Firefox bits, make them owners and peers, and I will no longer object. But it sounds like your intent is to seek rubber stamps from module owners/peers and merely "consult with [them when] starting with initial designs". If you're going to do that, all I'm asking is that you find a Firefox peer who is willing to vouch for your proposal now, by saying "In my opinion, Ben, Jed, Mark, and Lloyd know enough to review patches in Firefox, and if they screw anything up, I will personally ensure that things are righted in a timely fashion." If the peer is confident that you guys aren't going to screw anything up, this commitment requires zero work, so I don't buy the "nobody has time" argument. If on the other hand nobody is willing to take personal responsibility for this proposed structure, then I'd think that's a strong sign of no confidence from our experts, and I would continue to object to this proposal. But please keep in mind that I am not a peer of the module ownership structure, so I'll be objecting from up in the peanut gallery. You'll scarcely be able to hear me from your seats. :) -Justin _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
