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 >> >>
