spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "witgo" <wi...@qq.com>
Subject 回复: [VOTE] Designating maintainers for some Spark components
Date Thu, 06 Nov 2014 07:30:44 GMT
+1




------------------ 原始邮件 ------------------
发件人: "Matei Zaharia"<matei.zaharia@gmail.com>; 
发送时间: 2014年11月6日(星期四) 下午3:21
收件人: "Sean Owen"<sowen@cloudera.com>; 
抄送: "dev"<dev@spark.apache.org>; 
主题: Re: [VOTE] Designating maintainers for some Spark components



Several people asked about having maintainers review the PR queue for their modules regularly,
and I like that idea. We have a new tool now to help with that in https://spark-prs.appspot.com.

In terms of the set of open PRs itself, it is large but note that there are also 2800 *closed*
PRs, which means we close the majority of PRs (and I don't know the exact stats but I'd guess
that 90% of those are accepted and merged). I think one problem is that with GitHub, people
often develop something as a PR and have a lot of discussion on there (including whether we
even want the feature). I recently updated our "how to contribute" page to encourage opening
a JIRA and having discussions on the dev list first, but I do think we need to be faster with
closing ones that we don't have a plan to merge. Note that Hadoop, Hive, HBase, etc also have
about 300 issues each in the "patch available" state, so this is some kind of universal constant
:P.

Matei


> On Nov 5, 2014, at 10:46 PM, Sean Owen <sowen@cloudera.com> wrote:
> 
> Naturally, this sounds great. FWIW my only but significant worry about
> Spark is scaling up to meet unprecedented demand in the form of
> questions and contribution. Clarifying responsibility and ownership
> helps more than it hurts by adding process.
> 
> This is related but different topic, but, I wonder out loud what this
> can do to help clear the backlog -- ~*1200* open JIRAs and ~300 open
> PRs, most of which have de facto already fallen between some cracks.
> This harms the usefulness of these tools and processes.
> 
> I'd love to see this translate into triage / closing of most of it by
> maintainers, and new actions and strategies for increasing
> 'throughput' in review and/or helping people make better contributions
> in the first place.
> 
> On Thu, Nov 6, 2014 at 1:31 AM, Matei Zaharia <matei.zaharia@gmail.com> wrote:
>> Hi all,
>> 
>> I wanted to share a discussion we've been having on the PMC list, as well as call
for an official vote on it on a public list. Basically, as the Spark project scales up, we
need to define a model to make sure there is still great oversight of key components (in particular
internal architecture and public APIs), and to this end I've proposed implementing a maintainer
model for some of these components, similar to other large projects.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
For additional commands, e-mail: dev-help@spark.apache.org
Mime
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message