> With the maintainer model, the process is as follows: > > - Any committer could review the patch and merge it, but they would need to > forward it to me (or another core API maintainer) to make sure we also approve > - At any point during this process, I could come in and -1 it, or give > feedback > - In addition, any other committer beyond me is still allowed to -1 this patch > > The only change in this model is that committers are responsible to forward > patches in these areas to certain other committers. If every committer had > perfect oversight of the project, they could have also seen every patch to > their component on their own, but this list ensures that they see it even if > they somehow overlooked it.
Having done the job of playing an informal 'maintainer' of a project myself, this is what I think you really need: The so called 'maintainers' do one of the below - Actively poll the lists and watch over contributions. And follow what is repeated often around here: Trust but verify. - Setup automated mechanisms to send all bug-tracker updates of a specific component to a list that people can subscribe to And/or - Individual contributors send review requests to unofficial 'maintainers' over dev-lists or through tools. Like many projects do with review boards and other tools. Note that none of the above is a required step. It must not be, that's the point. But once set as a convention, they will all help you address your concerns with project scalability. Anything else that you add is bestowing privileges to a select few and forming dictatorships. And contrary to what the proposal claims, this is neither scalable nor confirming to Apache governance rules. +Vinod
signature.asc
Description: Message signed with OpenPGP using GPGMail
