spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vaquar khan <vaquar.k...@gmail.com>
Subject Re: [VOTE] Designating maintainers for some Spark components
Date Sat, 08 Nov 2014 05:59:43 GMT
+1 (binding)
On 8 Nov 2014 07:26, "Davies Liu" <davies@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 <davies@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
> > <vinodkv@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-unsubscribe@spark.apache.org
> For additional commands, e-mail: dev-help@spark.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message