Re: Improving metadata in Spark JIRA

[Nicholas Chammas]

Open pull request count is down to 254 right now from ~325 several weeks
ago.

This great. Ideally, we need to get this down to < 50 and keep it there.
Having so many open pull requests is just a bad signal to contributors. But
it will take some time to get there.


   - 1+ Component

 Sean, do you have permission to edit our JIRA settings? It should be
possible to enforce this in JIRA itself.


   - 1+ Affects version

 I don’t think this field makes sense for improvements, right?

Nick
​

On Sun Feb 22 2015 at 9:43:24 AM Sean Owen  wrote:

> Open pull request count is down to 254 right now from ~325 several weeks
> ago.
> Open JIRA count is down slightly to 1262 from a peak over ~1320.
> Obviously, in the face of an ever faster and larger stream of
> contributions.
>
> There's a real positive impact of JIRA being a little more meaningful, a
> little less backlog to keep looking at, getting commits in slightly faster,
> slightly happier contributors, etc.
>
>
> The virtuous circle can keep going. It'd be great if every contributor
> could take a moment to look at his or her open PRs and JIRAs. Example
> searches (replace with your user name / name):
>
> https://github.com/apache/spark/pulls/srowen
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20SPARK%20AND%20reporter%20%3D%20%22Sean%20Owen%22%
> 20or%20assignee%20%3D%20%22Sean%20Owen%22
>
> For PRs:
>
> - if it appears to be waiting on your action or feedback,
>   - push more changes and/or reply to comments, or
>   - if it isn't work you can pursue in the immediate future, close the PR
>
> - if it appears to be waiting on others,
>   - if it's had feedback and it's unclear whether there's support to commit
> as-is,
> - break down or reduce the change to something less controversial
> - close the PR as softly rejected
>   - if there's no feedback or plainly waiting for action, ping @them
>
> For JIRAs:
>
> - If it's fixed along the way, or obsolete, resolve as Fixed or NotAProblem
>
> - Do a quick search to see if a similar issue has been filed and is
> resolved or has more activity; resolve as Duplicate if so
>
> - Check that fields are assigned reasonably:
>   - Meaningful title and description
>   - Reasonable type and priority. Not everything is a major bug, and few
> are blockers
>   - 1+ Component
>   - 1+ Affects version
>   - Avoid setting target version until it looks like there's momentum to
> merge a resolution
>
> - If the JIRA has had no activity in a long time (6+ months), but does not
> feel obsolete, try to move it to some resolution:
>   - Request feedback, from specific people if desired, to feel out if there
> is any other support for the change
>   - Add more info, like a specific reproduction for bugs
>   - Narrow scope of feature requests to something that contains a few
> actionable steps, instead of broad open-ended wishes
>   - Work on a fix. In an ideal world people are willing to work to resolve
> JIRAs they open, and don't fire-and-forget
>
>
> If everyone did this, not only would it advance the house-cleaning a bit
> more, but I'm sure we'd rediscover some important work and issues that need
> attention.
>
>
> On Sun, Feb 22, 2015 at 7:54 AM, Nicholas Chammas <
> nicholas.cham...@gmail.com> wrote:
>
> > As of right now, there are no more open JIRA issues without an assigned
> > component
> >  3D%20SPARK%20AND%20resolution%20%3D%20Unresolved%20AND%
> 20component%20%3D%20EMPTY%20ORDER%20BY%20updated%20DESC>!
> > Hurray!
> >
> > [image: yay]
> >
> > Thanks to Sean and others for the cleanup!
> >
> > Nick
> >
> > ​
> >
>

Re: Improving metadata in Spark JIRA

[Sean Owen]

Open pull request count is down to 254 right now from ~325 several weeks
ago.
Open JIRA count is down slightly to 1262 from a peak over ~1320.
Obviously, in the face of an ever faster and larger stream of contributions.

There's a real positive impact of JIRA being a little more meaningful, a
little less backlog to keep looking at, getting commits in slightly faster,
slightly happier contributors, etc.


The virtuous circle can keep going. It'd be great if every contributor
could take a moment to look at his or her open PRs and JIRAs. Example
searches (replace with your user name / name):

https://github.com/apache/spark/pulls/srowen
https://issues.apache.org/jira/issues/?jql=project%20%3D%20SPARK%20AND%20reporter%20%3D%20%22Sean%20Owen%22%20or%20assignee%20%3D%20%22Sean%20Owen%22

For PRs:

- if it appears to be waiting on your action or feedback,
  - push more changes and/or reply to comments, or
  - if it isn't work you can pursue in the immediate future, close the PR

- if it appears to be waiting on others,
  - if it's had feedback and it's unclear whether there's support to commit
as-is,
- break down or reduce the change to something less controversial
- close the PR as softly rejected
  - if there's no feedback or plainly waiting for action, ping @them

For JIRAs:

- If it's fixed along the way, or obsolete, resolve as Fixed or NotAProblem

- Do a quick search to see if a similar issue has been filed and is
resolved or has more activity; resolve as Duplicate if so

- Check that fields are assigned reasonably:
  - Meaningful title and description
  - Reasonable type and priority. Not everything is a major bug, and few
are blockers
  - 1+ Component
  - 1+ Affects version
  - Avoid setting target version until it looks like there's momentum to
merge a resolution

- If the JIRA has had no activity in a long time (6+ months), but does not
feel obsolete, try to move it to some resolution:
  - Request feedback, from specific people if desired, to feel out if there
is any other support for the change
  - Add more info, like a specific reproduction for bugs
  - Narrow scope of feature requests to something that contains a few
actionable steps, instead of broad open-ended wishes
  - Work on a fix. In an ideal world people are willing to work to resolve
JIRAs they open, and don't fire-and-forget


If everyone did this, not only would it advance the house-cleaning a bit
more, but I'm sure we'd rediscover some important work and issues that need
attention.


On Sun, Feb 22, 2015 at 7:54 AM, Nicholas Chammas <
nicholas.cham...@gmail.com> wrote:

> As of right now, there are no more open JIRA issues without an assigned
> component
> !
> Hurray!
>
> [image: yay]
>
> Thanks to Sean and others for the cleanup!
>
> Nick
>
> ​
>

Re: Improving metadata in Spark JIRA

[Nicholas Chammas]

As of right now, there are no more open JIRA issues without an assigned
component
!
Hurray!

[image: yay]

Thanks to Sean and others for the cleanup!

Nick

On Sat Feb 07 2015 at 8:29:42 PM Nicholas Chammas nicholas.cham...@gmail.com
 wrote:

Oh derp, missed the YARN component.
>
> JIRA, does allow admins to make fields mandatory:
> https://confluence.atlassian.com/display/JIRA/Specifying+Field+Behavior#SpecifyingFieldBehavior-Makingafieldrequiredoroptional
>
> Nick
>
> On Sat Feb 07 2015 at 5:23:10 PM Patrick Wendell 
> wrote:
>
>> I think we already have a YARN component.
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%
>> 20SPARK%20AND%20component%20%3D%20YARN
>>
>> I don't think JIRA allows it to be mandatory, but if it does, that
>> would be useful.
>>
>> On Sat, Feb 7, 2015 at 5:08 PM, Nicholas Chammas
>>  wrote:
>> > By the way, isn't it possible to make the "Component" field mandatory
>> when
>> > people open new issues? Shouldn't we do that?
>> >
>> > Btw Patrick, don't we need a YARN component? I think our JIRA components
>> > should roughly match the components on the PR dashboard.
>> >
>> > Nick
>> >
>> > On Fri Feb 06 2015 at 12:25:52 PM Patrick Wendell 
>> > wrote:
>> >>
>> >> Per Nick's suggestion I added two components:
>> >>
>> >> 1. Spark Submit
>> >> 2. Spark Scheduler
>> >>
>> >> I figured I would just add these since if we decide later we don't
>> >> want them, we can simply merge them into Spark Core.
>> >>
>> >> On Fri, Feb 6, 2015 at 11:53 AM, Nicholas Chammas
>> >>  wrote:
>> >> > Do we need some new components to be added to the JIRA project?
>> >> >
>> >> > Like:
>> >> >
>> >> >-
>> >> >
>> >> >scheduler
>> >> > -
>> >> >
>> >> >YARN
>> >> > - spark-submit
>> >> >- ...?
>> >> >
>> >> > Nick
>> >> >
>> >> >
>> >> > On Fri Feb 06 2015 at 10:50:41 AM Nicholas Chammas <
>> >> > nicholas.cham...@gmail.com> wrote:
>> >> >
>> >> >> +9000 on cleaning up JIRA.
>> >> >>
>> >> >> Thank you Sean for laying out some specific things to tackle. I will
>> >> >> assist with this.
>> >> >>
>> >> >> Regarding email, I think Sandy is right. I only get JIRA email for
>> >> >> issues
>> >> >> I'm watching.
>> >> >>
>> >> >> Nick
>> >> >>
>> >> >> On Fri Feb 06 2015 at 9:52:58 AM Sandy Ryza <
>> sandy.r...@cloudera.com>
>> >> >> wrote:
>> >> >>
>> >> >>> JIRA updates don't go to this list, they go to
>> >> >>> iss...@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 
>> 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-unsubscr...@spark.apache.org
>> >> >>> > For additional commands, e-mail: dev-h...@spark.apache.org
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >> >>
>>
> ​

Re: Improving metadata in Spark JIRA

[Nicholas Chammas]

By the way, isn't it possible to make the "Component" field mandatory when
people open new issues? Shouldn't we do that?

Btw Patrick, don't we need a YARN component? I think our JIRA components
should roughly match the components on the PR dashboard
.

Nick

On Fri Feb 06 2015 at 12:25:52 PM Patrick Wendell 
wrote:

> Per Nick's suggestion I added two components:
>
> 1. Spark Submit
> 2. Spark Scheduler
>
> I figured I would just add these since if we decide later we don't
> want them, we can simply merge them into Spark Core.
>
> On Fri, Feb 6, 2015 at 11:53 AM, Nicholas Chammas
>  wrote:
> > Do we need some new components to be added to the JIRA project?
> >
> > Like:
> >
> >-
> >
> >scheduler
> > -
> >
> >YARN
> > - spark-submit
> >- ...?
> >
> > Nick
> >
> >
> > On Fri Feb 06 2015 at 10:50:41 AM Nicholas Chammas <
> > nicholas.cham...@gmail.com> wrote:
> >
> >> +9000 on cleaning up JIRA.
> >>
> >> Thank you Sean for laying out some specific things to tackle. I will
> >> assist with this.
> >>
> >> Regarding email, I think Sandy is right. I only get JIRA email for
> issues
> >> I'm watching.
> >>
> >> Nick
> >>
> >> On Fri Feb 06 2015 at 9:52:58 AM Sandy Ryza 
> >> wrote:
> >>
> >>> JIRA updates don't go to this list, they go to iss...@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  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-unsubscr...@spark.apache.org
> >>> > For additional commands, e-mail: dev-h...@spark.apache.org
> >>> >
> >>> >
> >>>
> >>
>

Re: Improving metadata in Spark JIRA

[Nicholas Chammas]

Oh derp, missed the YARN component.

JIRA, does allow admins to make fields mandatory:
https://confluence.atlassian.com/display/JIRA/Specifying+Field+Behavior#SpecifyingFieldBehavior-Makingafieldrequiredoroptional

Nick

On Sat Feb 07 2015 at 5:23:10 PM Patrick Wendell  wrote:

> I think we already have a YARN component.
>
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20SPARK%20AND%20component%20%3D%20YARN
>
> I don't think JIRA allows it to be mandatory, but if it does, that
> would be useful.
>
> On Sat, Feb 7, 2015 at 5:08 PM, Nicholas Chammas
>  wrote:
> > By the way, isn't it possible to make the "Component" field mandatory
> when
> > people open new issues? Shouldn't we do that?
> >
> > Btw Patrick, don't we need a YARN component? I think our JIRA components
> > should roughly match the components on the PR dashboard.
> >
> > Nick
> >
> > On Fri Feb 06 2015 at 12:25:52 PM Patrick Wendell 
> > wrote:
> >>
> >> Per Nick's suggestion I added two components:
> >>
> >> 1. Spark Submit
> >> 2. Spark Scheduler
> >>
> >> I figured I would just add these since if we decide later we don't
> >> want them, we can simply merge them into Spark Core.
> >>
> >> On Fri, Feb 6, 2015 at 11:53 AM, Nicholas Chammas
> >>  wrote:
> >> > Do we need some new components to be added to the JIRA project?
> >> >
> >> > Like:
> >> >
> >> >-
> >> >
> >> >scheduler
> >> > -
> >> >
> >> >YARN
> >> > - spark-submit
> >> >- ...?
> >> >
> >> > Nick
> >> >
> >> >
> >> > On Fri Feb 06 2015 at 10:50:41 AM Nicholas Chammas <
> >> > nicholas.cham...@gmail.com> wrote:
> >> >
> >> >> +9000 on cleaning up JIRA.
> >> >>
> >> >> Thank you Sean for laying out some specific things to tackle. I will
> >> >> assist with this.
> >> >>
> >> >> Regarding email, I think Sandy is right. I only get JIRA email for
> >> >> issues
> >> >> I'm watching.
> >> >>
> >> >> Nick
> >> >>
> >> >> On Fri Feb 06 2015 at 9:52:58 AM Sandy Ryza  >
> >> >> wrote:
> >> >>
> >> >>> JIRA updates don't go to this list, they go to
> >> >>> iss...@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 
> 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-unsubscr...@spark.apache.org
> >> >>> > For additional commands, e-mail: dev-h...@spark.apache.org
> >> >>> >
> >> >>> >
> >> >>>
> >> >>
>

Re: Improving metadata in Spark JIRA

[Patrick Wendell]

I think we already have a YARN component.

https://issues.apache.org/jira/issues/?jql=project%20%3D%20SPARK%20AND%20component%20%3D%20YARN

I don't think JIRA allows it to be mandatory, but if it does, that
would be useful.

On Sat, Feb 7, 2015 at 5:08 PM, Nicholas Chammas
 wrote:
> By the way, isn't it possible to make the "Component" field mandatory when
> people open new issues? Shouldn't we do that?
>
> Btw Patrick, don't we need a YARN component? I think our JIRA components
> should roughly match the components on the PR dashboard.
>
> Nick
>
> On Fri Feb 06 2015 at 12:25:52 PM Patrick Wendell 
> wrote:
>>
>> Per Nick's suggestion I added two components:
>>
>> 1. Spark Submit
>> 2. Spark Scheduler
>>
>> I figured I would just add these since if we decide later we don't
>> want them, we can simply merge them into Spark Core.
>>
>> On Fri, Feb 6, 2015 at 11:53 AM, Nicholas Chammas
>>  wrote:
>> > Do we need some new components to be added to the JIRA project?
>> >
>> > Like:
>> >
>> >-
>> >
>> >scheduler
>> > -
>> >
>> >YARN
>> > - spark-submit
>> >- ...?
>> >
>> > Nick
>> >
>> >
>> > On Fri Feb 06 2015 at 10:50:41 AM Nicholas Chammas <
>> > nicholas.cham...@gmail.com> wrote:
>> >
>> >> +9000 on cleaning up JIRA.
>> >>
>> >> Thank you Sean for laying out some specific things to tackle. I will
>> >> assist with this.
>> >>
>> >> Regarding email, I think Sandy is right. I only get JIRA email for
>> >> issues
>> >> I'm watching.
>> >>
>> >> Nick
>> >>
>> >> On Fri Feb 06 2015 at 9:52:58 AM Sandy Ryza 
>> >> wrote:
>> >>
>> >>> JIRA updates don't go to this list, they go to
>> >>> iss...@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  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-unsubscr...@spark.apache.org
>> >>> > For additional commands, e-mail: dev-h...@spark.apache.org
>> >>> >
>> >>> >
>> >>>
>> >>

-
To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org
For additional commands, e-mail: dev-h...@spark.apache.org

Re: Improving metadata in Spark JIRA

[Patrick Wendell]

Per Nick's suggestion I added two components:

1. Spark Submit
2. Spark Scheduler

I figured I would just add these since if we decide later we don't
want them, we can simply merge them into Spark Core.

On Fri, Feb 6, 2015 at 11:53 AM, Nicholas Chammas
 wrote:
> Do we need some new components to be added to the JIRA project?
>
> Like:
>
>-
>
>scheduler
> -
>
>YARN
> - spark-submit
>- ...?
>
> Nick
>
>
> On Fri Feb 06 2015 at 10:50:41 AM Nicholas Chammas <
> nicholas.cham...@gmail.com> wrote:
>
>> +9000 on cleaning up JIRA.
>>
>> Thank you Sean for laying out some specific things to tackle. I will
>> assist with this.
>>
>> Regarding email, I think Sandy is right. I only get JIRA email for issues
>> I'm watching.
>>
>> Nick
>>
>> On Fri Feb 06 2015 at 9:52:58 AM Sandy Ryza 
>> wrote:
>>
>>> JIRA updates don't go to this list, they go to iss...@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  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-unsubscr...@spark.apache.org
>>> > For additional commands, e-mail: dev-h...@spark.apache.org
>>> >
>>> >
>>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org
For additional commands, e-mail: dev-h...@spark.apache.org

Re: Improving metadata in Spark JIRA

[Hari Shreedharan]

+1. Jira cleanup would be good. Please let me know if I can help in some way!




Thanks, Hari

On Fri, Feb 6, 2015 at 11:56 AM, Nicholas Chammas
 wrote:

> Do we need some new components to be added to the JIRA project?
> Like:
>-
>scheduler
> -
>YARN
> - spark-submit
>- …?
> Nick
> ​
> On Fri Feb 06 2015 at 10:50:41 AM Nicholas Chammas <
> nicholas.cham...@gmail.com> wrote:
>> +9000 on cleaning up JIRA.
>>
>> Thank you Sean for laying out some specific things to tackle. I will
>> assist with this.
>>
>> Regarding email, I think Sandy is right. I only get JIRA email for issues
>> I'm watching.
>>
>> Nick
>>
>> On Fri Feb 06 2015 at 9:52:58 AM Sandy Ryza 
>> wrote:
>>
>>> JIRA updates don't go to this list, they go to iss...@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  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-unsubscr...@spark.apache.org
>>> > For additional commands, e-mail: dev-h...@spark.apache.org
>>> >
>>> >
>>>
>>

Re: Improving metadata in Spark JIRA

[Nicholas Chammas]

Do we need some new components to be added to the JIRA project?

Like:

   -

   scheduler
-

   YARN
- spark-submit
   - …?

Nick
​

On Fri Feb 06 2015 at 10:50:41 AM Nicholas Chammas <
nicholas.cham...@gmail.com> wrote:

> +9000 on cleaning up JIRA.
>
> Thank you Sean for laying out some specific things to tackle. I will
> assist with this.
>
> Regarding email, I think Sandy is right. I only get JIRA email for issues
> I'm watching.
>
> Nick
>
> On Fri Feb 06 2015 at 9:52:58 AM Sandy Ryza 
> wrote:
>
>> JIRA updates don't go to this list, they go to iss...@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  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-unsubscr...@spark.apache.org
>> > For additional commands, e-mail: dev-h...@spark.apache.org
>> >
>> >
>>
>

Re: Improving metadata in Spark JIRA

[Nicholas Chammas]

+9000 on cleaning up JIRA.

Thank you Sean for laying out some specific things to tackle. I will assist
with this.

Regarding email, I think Sandy is right. I only get JIRA email for issues
I'm watching.

Nick

On Fri Feb 06 2015 at 9:52:58 AM Sandy Ryza  wrote:

> JIRA updates don't go to this list, they go to iss...@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  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-unsubscr...@spark.apache.org
> > For additional commands, e-mail: dev-h...@spark.apache.org
> >
> >
>

Re: Improving metadata in Spark JIRA

[Sandy Ryza]

JIRA updates don't go to this list, they go to iss...@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  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-unsubscr...@spark.apache.org
> For additional commands, e-mail: dev-h...@spark.apache.org
>
>