Was thinking that getting an estimated statistic of the number of issues that would be closed if this is done would help.
Open issues: 3882 (project = SPARK AND status in (Open, "In Progress", Reopened)) Open + Does not affect 3.0+ = 2795 Open + Does not affect 2.4+ = 2373 Open + Does not affect 2.3+ = 1765 Open + Does not affect 2.2+ = 1322 Open + Does not affect 2.1+ = 967 Open + Does not affect 2.0+ = 651 Open + Does not affect 2.0+ + Priority in (Urgent, Blocker, Critical, High) [JQL1] = 838 Open + Does not affect 2.0+ + Priority in (Urgent, Blocker, Critical, High, Major) = 206 Open + Does not affect 2.2+ + Priority not in (Urgent, Blocker, Critical, High) [JQL2] = 1303 Open + Does not affect 2.2+ + Priority not in (Urgent, Blocker, Critical, High, Major) = 397 Open + Does not affect 2.3+ + Priority not in (Urgent, Blocker, Critical, High) = 1743 Open + Does not affect 2.3+ + Priority not in (Urgent, Blocker, Critical, High, Major) = 550 Resolving ALL seems a bit overkill to me. My current opinion seems like: - Resolving "Open + Does not affect 2.0+" is something that should be done, as I doubt anyone would be looking at the 1.x versions anymore (651 tasks) - Resolving "Open + Does not affect 2.3+ + Priority not in (Urgent, Blocker, Critical, High, Major)" may be a good idea (an additional ~1k tasks) The issues with priority Urgent/Blocker/Critical should be triaged - as it may have something important. [JQL1]: project = SPARK AND status in (Open, "In Progress", Reopened) AND NOT (affectedVersion in versionMatch("^[2-3].*")) AND priority NOT IN (Urgent, Blocker, Critical, High) [JQL2]: project = SPARK AND status in (Open, "In Progress", Reopened) AND NOT (affectedVersion in versionMatch("^3.*") OR affectedVersion in versionMatch("^2.4.*") OR affectedVersion in versionMatch("^2.3.*") OR affectedVersion in versionMatch("^2.2.*")) AND priority NOT IN (Urgent, Blocker, Critical, High) On Wed, May 15, 2019, 14:55 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. >