XPCOM Ownership and Code Review Policy

[Doug Turner]

If you are on the TO list of this email, please respond by Feb 20 with your thoughts on this matter:

XPCOM Peers,
I would like to break up and distribute the ownership responsibilities of XPCOM. This really isn�t something new, but rather I just want to formalize what we have been doing. The ownership distribution of XPCOM can roughly be described by the set of directories under mozilla/xpcom. I would like to make known and public those that are responsible for these areas.

Note that there are a few areas within the xpcom directory where what I proposed doesn't apply. nsCOMPtr falls into this set. Another is brendan's double hash stuff. I am sure that there are others. For changes to those areas, the "module" (in our case directory) owner of course seek the advice and review of the expert.

OWNERSHIP

[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

xpcom/glue
xpcom/base
xpcom/components
xpcom/sample
xpcom/tools

[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

xpcom/reflect
xpcom/typelib
xpcom/libxpt

[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]>

xpcom/ds

[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]>

xpcom/io

Shared responsibility (the buck stops with dougt)

xpcom/threads

REVIEW POLICY

I would like to ensure that all check-in to mozilla/xpcom require a review from one of us. Furthermore, any new code must be run by � not necessary reviewed by me (this is to ensure that xpcom doesn�t continue to be a dumping ground for all things that don�t fit elsewhere.)

Because, our module does have strong ownership, I would like to end the requirement of having check-ins requiring a �super review�. XPCOM "directory" owners can stay with the SR policy if they like (as it is more restrictive than the one that I apply to mozilla/xpcom, however it is completely up to that owner.


Regards,

--
Doug Turner
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>