As of right now, there are no more open JIRA issues without an assigned component <https://issues.apache.org/jira/issues/?jql=project%20%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 On Sat Feb 07 2015 at 8:29:42 PM Nicholas Chammas nicholas.cham...@gmail.com <http://mailto: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 <pwend...@gmail.com> > 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 >> <nicholas.cham...@gmail.com> 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 <pwend...@gmail.com> >> > 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 >> >> <nicholas.cham...@gmail.com> 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 <so...@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-unsubscr...@spark.apache.org >> >> >>> > For additional commands, e-mail: dev-h...@spark.apache.org >> >> >>> > >> >> >>> > >> >> >>> >> >> >> >> >
