+1 (binding) On 8 Nov 2014 07:26, "Davies Liu" <dav...@databricks.com> wrote:
> Sorry for my last email, I misunderstood the proposal here, all the > committer still have equal -1 to all the code changes. > > Also, as mentioned in the proposal, the sign off only happens to > public API and architect, something like discussion about code style > things are still the same. > > So, I'd revert my vote to +1. Sorry for this. > > Davies > > > On Fri, Nov 7, 2014 at 3:18 PM, Davies Liu <dav...@databricks.com> wrote: > > -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 > >
