spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandy Ryza <sandy.r...@cloudera.com>
Subject Re: Improving metadata in Spark JIRA
Date Fri, 06 Feb 2015 17:50:15 GMT
JIRA updates don't go to this list, they go to issues@spark.apache.org.  I
don't think many are signed up for that list, and those that are probably
have a flood of emails anyway.

So I'd definitely be in favor of any JIRA cleanup that you're up for.

-Sandy

On Fri, Feb 6, 2015 at 6:45 AM, Sean Owen <sowen@cloudera.com> wrote:

> I've wasted no time in wielding the commit bit to complete a number of
> small, uncontroversial changes. I wouldn't commit anything that didn't
> already appear to have review, consensus and little risk, but please
> let me know if anything looked a little too bold, so I can calibrate.
>
>
> Anyway, I'd like to continue some small house-cleaning by improving
> the state of JIRA's metadata, in order to let it give us a little
> clearer view on what's happening in the project:
>
> a. Add Component to every (open) issue that's missing one
> b. Review all Critical / Blocker issues to de-escalate ones that seem
> obviously neither
> c. Correct open issues that list a Fix version that has already been
> released
> d. Close all issues Resolved for a release that has already been released
>
> The problem with doing so is that it will create a tremendous amount
> of email to the list, like, several hundred. It's possible to make
> bulk changes and suppress e-mail though, which could be done for all
> but b.
>
> Better to suppress the emails when making such changes? or just not
> bother on some of these?
>
> ---------------------------------------------------------------------
> 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