+1, too. Thank you, Hyukjin!
Bests, Dongjoon. On Fri, May 17, 2019 at 9:07 AM Imran Rashid <iras...@cloudera.com.invalid> wrote: > +1, thanks for taking this on > > On Wed, May 15, 2019 at 7:26 PM Hyukjin Kwon <gurwls...@gmail.com> wrote: > >> oh, wait. 'Incomplete' can still make sense in this way then. >> Yes, I am good with 'Incomplete' too. >> >> 2019년 5월 16일 (목) 오전 11:24, Hyukjin Kwon <gurwls...@gmail.com>님이 작성: >> >>> I actually recently used 'Incomplete' a bit when the JIRA is basically >>> too poorly formed (like just copying and pasting an error) ... >>> >>> I was thinking about 'Unresolved' status or `Auto Closed' too. I double >>> checked they can be reopen as well after resolution. >>> >>> [image: Screen Shot 2019-05-16 at 10.35.14 AM.png] >>> [image: Screen Shot 2019-05-16 at 10.35.39 AM.png] >>> >>> 2019년 5월 16일 (목) 오전 11:04, Sean Owen <sro...@gmail.com>님이 작성: >>> >>>> Agree, anything without an Affected Version should be old enough to >>>> time out. >>>> I might use "Incomplete" or something as the status, as we haven't >>>> otherwise used that. Maybe that's simpler than a label. But, anything like >>>> that sounds good. >>>> >>>> On Wed, May 15, 2019 at 8:40 PM Hyukjin Kwon <gurwls...@gmail.com> >>>> wrote: >>>> >>>>> BTW, affected version became a required field (I don't remember when >>>>> exactly was .. I believe it's around when we work on Spark 2.3): >>>>> >>>>> [image: Screen Shot 2019-05-16 at 10.29.50 AM.png] >>>>> >>>>> So, including all EOL versions and affected versions not specified >>>>> will roughly work. >>>>> Using "Cannot Reproduce" as its status and 'bulk-closed' label makes >>>>> the best sense to me. >>>>> >>>>> Okie. I want to open this roughly for a week before taking an actual >>>>> action for this. If there's no more feedback, I will do as I said ^ next >>>>> week. >>>>> >>>>> >>>>> 2019년 5월 15일 (수) 오후 11:33, Josh Rosen <rosenvi...@gmail.com>님이 작성: >>>>> >>>>>> +1 in favor of some sort of JIRA cleanup. >>>>>> >>>>>> My only request is that we attach some sort of 'bulk-closed' label to >>>>>> issues that we close via JIRA filter batch operations (and resolve the >>>>>> issues as "Timed Out" / "Cannot Reproduce", not "Fixed"). Using a label >>>>>> makes it easier to audit what was closed, simplifying the process of >>>>>> identifying and re-opening valid issues caught in our dragnet. >>>>>> >>>>>> >>>>>> On Wed, May 15, 2019 at 7:19 AM Sean Owen <sro...@gmail.com> wrote: >>>>>> >>>>>>> I gave up looking through JIRAs a long time ago, so, big respect for >>>>>>> continuing to try to triage them. I am afraid we're missing a few >>>>>>> important bug reports in the torrent, but most JIRAs are not >>>>>>> well-formed, just questions, stale, or simply things that won't be >>>>>>> added. I do think it's important to reflect that reality, and so I'm >>>>>>> always in favor of more aggressively closing JIRAs. I think this is >>>>>>> more standard practice, from projects like TensorFlow/Keras, pandas, >>>>>>> etc to just automatically drop Issues that don't see activity for N >>>>>>> days. We won't do that, but, are probably on the other hand far too >>>>>>> lax in closing them. >>>>>>> >>>>>>> Remember that JIRAs stay searchable and can be reopened, so it's not >>>>>>> like we lose much information. >>>>>>> >>>>>>> I'd close anything that hasn't had activity in 2 years (?), as a >>>>>>> start. >>>>>>> I like the idea of closing things that only affect an EOL release, >>>>>>> but, many items aren't marked, so may need to cast the net wider. >>>>>>> >>>>>>> I think only then does it make sense to look at bothering to >>>>>>> reproduce >>>>>>> or evaluate the 1000s that will still remain. >>>>>>> >>>>>>> On Wed, May 15, 2019 at 4:25 AM Hyukjin Kwon <gurwls...@gmail.com> >>>>>>> wrote: >>>>>>> > >>>>>>> > Hi all, >>>>>>> > >>>>>>> > I would like to propose to resolve all JIRAs that affects EOL >>>>>>> releases - 2.2 and below. and affected version >>>>>>> > not specified. I was rather against this way and considered this >>>>>>> as last resort in roughly 3 years ago >>>>>>> > when we discussed. Now I think we should go ahead with this. See >>>>>>> below. >>>>>>> > >>>>>>> > I have been talking care of this for so long time almost every day >>>>>>> those 3 years. The number of JIRAs >>>>>>> > keeps increasing and it does never go down. Now the number is >>>>>>> going over 2500 JIRAs. >>>>>>> > Did you guys know? in JIRA, we can only go through page by page up >>>>>>> to 1000 items. So, currently we're even >>>>>>> > having difficulties to go through every JIRA. We should manually >>>>>>> filter out and check each. >>>>>>> > The number is going over the manageable size. >>>>>>> > >>>>>>> > I am not suggesting this without anything actually trying. This is >>>>>>> what we have tried within my visibility: >>>>>>> > >>>>>>> > 1. In roughly 3 years ago, Sean tried to gather committers and >>>>>>> even non-committers people to sort >>>>>>> > out this number. At that time, we were only able to keep this >>>>>>> number as is. After we lost this momentum, >>>>>>> > it kept increasing back. >>>>>>> > 2. At least I scanned _all_ the previous JIRAs at least more >>>>>>> than two times and resolved them. Roughly >>>>>>> > once a year. The rest of them are mostly obsolete but not >>>>>>> enough information to investigate further. >>>>>>> > 3. I strictly stick to "Contributing to JIRA Maintenance" >>>>>>> https://spark.apache.org/contributing.html and >>>>>>> > resolve JIRAs. >>>>>>> > 4. Promoting other people to comment on JIRA or actively resolve >>>>>>> them. >>>>>>> > >>>>>>> > One of the facts I realised is the increasing number of committers >>>>>>> doesn't virtually help this much (although >>>>>>> > it might be helpful if somebody active in JIRA becomes a >>>>>>> committer.) >>>>>>> > >>>>>>> > One of the important thing I should note is that, it's now almost >>>>>>> pretty difficult to reproduce and test the >>>>>>> > issues found in EOL releases. We should git clone, checkout, build >>>>>>> and test. And then, see if that issue >>>>>>> > still exists in upstream, and fix. This is non-trivial overhead. >>>>>>> > >>>>>>> > Therefore, I would like to propose resolving _all_ the JIRAs that >>>>>>> targets EOL releases - 2.2 and below. >>>>>>> > Please let me know if anyone has some concerns or objections. >>>>>>> > >>>>>>> > Thanks. >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org >>>>>>> >>>>>>>
