Hello, > I liked the idea of 'Reviewers' more than any of the other options. > I would like to go with this patch, unless we find a much better > option?
to cancel this category of maintainers completely? I guess it was probably discussed before (I am too lazy to check), but the existence of non-self-approving maintainers does not make much sense to me. It definitely is a good idea to have someone else but you read your patch before committing it, but this general guideline should apply to everyone, not just to a special group of maintainers (and IMHO sending your patch to mailing list and waiting for people to comment on it before committing it is enough to achieve this). Let me state my reasons to dislike the existence of this category of maintainers. We have non-global maintainers for the following reasons: 1) to reduce the workload of the global maintainers, who would otherwise have to approve every single patch, and to do so, understand thoroughly every single component of the compiler. 2) to speed up the rate at which changes can be made to some specific components, by allowing the local maintainers to commit them without waiting for an external review. 3) to indicate what persons are responsible for bugs/features of the specific component. I will not mention this reason in further discussion, as it does not seem to be really all that important (there are other ways to share this information). The item 2) obviously does not apply to non-self-approving maintainers. Also, it does not make sense to have only one non-self-approving maintainer for some component, as most of the patches for the component would usually be written by him/her and would have to be approved by a global maintainer, thus making 1) not to apply as well. So the only situation when having non-self-approving maintainers makes at least some sense is when you have several co-maintainers for one component. However, in this case they usually work together and would discuss any significant changes to the component anyway, so making them as non-self-approving does not really change anything under normal circumstances. That being the case, I would prefer not to place formal restrictions on their maintainership and let them work out whatever mode of cooperation suits them the best (if it ever happened that co-maintainers of some component will not be willing to work together and cooperate, no artificial restriction will make this work, anyway). And finally, we will avoid the need to find weird words to describe this category of maintainers :-) Zdenek > Thanks. > > > > Index: MAINTAINERS > =================================================================== > --- MAINTAINERS (revision 126951) > +++ MAINTAINERS (working copy) > @@ -231,7 +231,7 @@ > maintainers need approval to check in algorithmic changes or changes > outside of the parts of the compiler they maintain. > > - Non-Autopoiesis Maintainers > + Reviewers > > dataflow Daniel Berlin [EMAIL PROTECTED] > dataflow Paolo Bonzini [EMAIL PROTECTED] > @@ -251,10 +251,9 @@ > Fortran Paul Thomas [EMAIL PROTECTED] > > > -Note that individuals who maintain parts of the compiler as > -non-autopoiesis maintainers need approval changes outside of the parts > -of the compiler they maintain and also need approval for their own > -patches. > +Note that individuals who maintain parts of the compiler as reviewers > +need approval changes outside of the parts of the compiler they > +maintain and also need approval for their own patches. > > Write After Approval (last name alphabetical order) >
