-1 (not binding, +1 for maintainer, -1 for sign off) Agree with Greg and Vinod. In the beginning, everything is better (more efficient, more focus), but after some time, fighting begins.
Code style is the most hot topic to fight (we already saw it in some PRs). If two committers (one of them is maintainer) have not got a agreement on code style, before this process, they will ask comments from other committers, but after this process, the maintainer have higher priority to -1, then maintainer will keep his/her personal preference, it's hard to make a agreement. Finally, different components will have different code style (or others). Right now, maintainers are kind of first contact or best contacts, the best person to review the PR in that component. We could announce it, then new contributors can easily find the right one to review. My 2 cents. Davies On Thu, Nov 6, 2014 at 11:43 PM, Vinod Kumar Vavilapalli <vino...@apache.org> wrote: >> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
