spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Burak Yavuz <>
Subject Re: Fwd: [jira] [Commented] (SPARK-6889) Streamline contribution process with update to Contribution wiki, JIRA rules
Date Tue, 14 Apr 2015 15:38:51 GMT
Hi Sean and fellow devs,
I also wanted to chime in and remind people of <>. Just
because the work of someone doesn't fit into the broader scope of things,
devs should be encouraged to showcase their hard work in Spark Packages.
We have been working hard to make it easier for devs to share their work
and users to access it in Spark Packages. There are some great datasource
connectors, ml algorithms, streaming connectors in there already. I would
urge devs and users to check it out!

On Apr 14, 2015 8:06 AM, "Sean Owen" <> wrote:

> Bringing a discussion to dev@. I think the general questions on the table
> are:
> - Should more changes be rejected? What are the pros/cons of that?
> - If no, how do you think about the very large backlog of PRs and JIRAs?
> - What should be rejected and why?
> - How much support is there for proactively cleaning house now? What
> would you close and why?
> - What steps can be taken to prevent people from wasting time on JIRAs
> / PRs that will be rejected?
> - What if anything does this tell us about the patterns of project
> planning to date and what can we learn?
> This overlaps with other discussion on SPARK-6889 but per Nicholas
> wanted to surface this
> ---------- Forwarded message ----------
> From: Nicholas Chammas (JIRA) <>
> Date: Tue, Apr 14, 2015 at 3:38 PM
> Subject: [jira] [Commented] (SPARK-6889) Streamline contribution
> process with update to Contribution wiki, JIRA rules
> To:
> Nicholas Chammas commented on SPARK-6889:
> -----------------------------------------
> {quote}
> I also agree that most projects don't say "no" enough and it's
> actually bad for everyone. Yes, one goal was to also set more
> expectation that lots of changes are rejected. If there is widespread
> agreement, I'd also like firmer language in the guide. As you say it
> is also a matter of taste and culture, but, I'd personally favor a lot
> more "no".
> {quote}
> Regarding this point about culture, should we have some kind of
> discussion on the dev list to nudge people in the right direction?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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