I'm fine with this and the divisions as listed. David
Doug Turner wrote:
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,
smime.p7s
Description: S/MIME Cryptographic Signature
