The problem isn't what to do with the old ones. The problem for the apache foundation is why there are so many patch-available PRS. Remember the apache software foundation is built on this meritocracy concept. If you do more you become a committer and then a PMC. But you can't do more if committers wonly help.
Every one of those jiras is someone who wanted to commit in some way and it didnt get there. There are many inequities in the apache/open source system. The most simple one is that people do have " natural groups". There might be 20 committers and 40% work at one company 30% work in another, the remaining 30% spread. 30% spread is a high number. For some projects it is 0 or 10%. This means that it is hard to find a "partner". In effect I am in the 10%, I have to go find a committer that is active, let's say there are 3. Then they have their "day job" and their "Day job". Their "day job" tends to land them reviewing PR of people mostly aligned with them, and surprise! That usually the other committers they work with at said day job. For example : This PR is done For months? https://issues.apache.org/jira/browse/HADOOP-19786 It takes only someone to merge the patch and run the plugin and see. It is maybe 5 minutes of work, Yet I have seen tickets created AFTER I was done with this PR merged, If I give up now It will fall into this group of "abandoned". What am I to take from this stituation? I have tthis suggestion 1) go take AI and and MCP jira plugin, ask it to "go through the tickets ' no one has time to read or triage'" and ask it to summarize them. Then take action comment on them reply to the autihor say "Hey our AI says your bug is bogus" "our ai says your feature is marginal and I agree" 2) do it by hand Just waiting a hand over every legit bug that no one feels like triaging ever 2 years is hiding the systematic problem. On Tue, Mar 31, 2026 at 4:43 PM Mukund Madhav Thakur <[email protected]> wrote: > IMO +1 for closing if the issues are not getting any updates in a decade. > Closing unattended issues reduces clutter in Jira and frees up mental space > for reviewing new items; of course, the issue can be reopened. > But I do understand the sentiment for leaving it open after reading > comments from other members. > > Thanks > Mukund > > > On Thu, Mar 26, 2026 at 10:43 AM Aaron Fabbri <[email protected]> wrote: > > > Good points. Agree if an issue hasn't had any comments for over a decade, > > it is unlikely to be significant. And resolving issues with a comment > > should avoid any confusion: > > > > "This issue has not been updated for <X> years, and has been marked as > > Abandoned. This does not mean the issue is not valid. Please reopen if > this > > issue is still valid. Alternately, if you know it is not valid, please > > leave a comment explaining and change resolution to Not A Bug" > > > > I think people are used to finding resolved bugs. When I'm searching for > a > > bug, I still look at closed bugs. Often they've already been Fixed or > > resolved, but my version doesn't have the fix yet. Other times the > project > > decided not to fix it. Either way, the bug is still documented and > > available for comments and reopening. > > > > Another idea is to use a "stale" label or other means of filtering issues > > that haven't been updated in a long time. > > > > > > On Thu, Mar 26, 2026 at 1:14 AM Xiaoqiao He <[email protected]> > wrote: > > > > > Great, Thanks for the detailed update. I didn't oppose resolving > > > these stale JIRAs, just some confusions are not very clear for me. > > > One obvious issue for example is that if the JIRA is really BUGs > > > but we didn't reach a consensus or didn't have a solution for it, we > > > close it or mark it as `abandoned` now, it could confuse to the end > > > users if the issue has been resolved or not. Of course, from another > > > view, one JIRA opened for many years without anymore progress > > > could not be one critical or important issue from my side. From this > > > point, closing them makes sense to me. One word, this is not one > > > blocker comment, I would like to see more suggestions. > > > Thanks. > > > > > > Best Regards, > > > - He Xiaoqiao > > > > > > > > > On Wed, Mar 25, 2026 at 3:32 AM Aaron Fabbri <[email protected]> > wrote: > > > > > > > On Tue, Mar 24, 2026 at 4:03 AM Xiaoqiao He <[email protected]> > > > wrote: > > > > > > > > > Thanks for starting this thread. It's a good topic. > > > > > +0 from my side. I don't get what's the profit if we close these > > stale > > > > > issues or keep the status as current. > > > > > > > > > > > > > Hi He, thanks for commenting. Let me try to explain the motivation a > > bit > > > > more. Why is bug triage important? > > > > > > > > There is a lot of research on the topic. I'm not very familiar with > it > > > all, > > > > but this may be a good starting point: > > https://arxiv.org/pdf/2511.08607 > > > > "Triage in Software Engineering: A Systematic Review of Research and > > > > Practice" > > > > > > > > TL;DR My understanding is: untriaged bug tracking is bad for quality > > and > > > > wastes time. > > > > > > > > It is like a signal to noise ratio. Say I want to answer the question > > > "What > > > > are the 10 most critical bugs in the project". I should be able to > > answer > > > > that question in a few minutes IMHO. Instead, we (I) spend a lot of > > time > > > > reading old JIRAs, looking if they even still are valid (the code > often > > > has > > > > changed). That effort is spent over and over again because we are not > > > > triaging our bugs. It is especially painful for people new to the > > > project, > > > > or coming back after a long break. > > > > > > > > I think we need to at least start manually closing old issues when we > > > can, > > > > after pinging the authors and giving them time to respond. Bugs can > > > always > > > > be reopened! > > > > > > > > Over 2000 Major priority issues just makes it difficult to understand > > the > > > > state of the codebase. For the sake of discussion, let's say they're > > all > > > > accurate. Then I'd argue we have significant quality issues and we > > should > > > > start prioritizing the most important fixes, since we are not keeping > > up. > > > > This prioritization process should to be surfaced in our isssue > > tracker, > > > > not in just our brains, so the greater community can participate in > > > > improvements. > > > > > > > > Similar reasons behind our auto-triaging of github issues; so we can > > > focus > > > > our limited (reviewer) time on issues that are current and ready for > > > > integration. > > > > > > > > Thank you, > > > > Aaron > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > Best Regards, > > > > > - He Xiaoqiao > > > > > > > > > > On Sat, Mar 21, 2026 at 11:33 AM Edward Capriolo < > > > [email protected]> > > > > > wrote: > > > > > > > > > > > Sorry to be crabby but it's like bringing back my PTSD. > > > > > > > > > > > > Would make a great talk for "https://communityovercode.org/"; > > > Wouldn't > > > > > it? > > > > > > ------------- > > > > > > Topic 1: > > > > > > https://issues.apache.org/jira/browse/HIVE-867?filter=-3 > > > > > > > > > > > > How many reviewers will go on vacation before merging my PR? Then > > > > after 3 > > > > > > reviewers and 4 rounds of comments. They give up and dont merge. > It > > > > goes > > > > > > stale. Just ask me to do it again! > > > > > > ----------------------- > > > > > > > > > > > > Now really, let me free myself from that rant. > > > > > > > > > > > > This linux container-executor is supposed to be the linchpin of > > > > "secure" > > > > > > hadoop. IMHO making the container-executor more robust by fixing > > > issues > > > > > > (pointer, double free, buffer overflow type stuff) is a big win > vs > > > one > > > > > > extraneous comment. > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Mar 20, 2026 at 10:41 PM Edward Capriolo < > > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > Larry, > > > > > > > > > > > > > > "As far as committers being in the business of cleaning up > > > > > > contributions, I > > > > > > > am mostly against this. > > > > > > > Contributors learn proper skills by getting things in - not be > > > others > > > > > > doing > > > > > > > it for them. > > > > > > > It can be painful but such is growth." > > > > > > > > > > > > > > Larry, it is not a skill to sit around and wait 4 days for a > > > review. > > > > > > This > > > > > > > is what happens to me quite often. > > > > > > > > > > > > > > submitter: 5 line PR. > > > > > > > submitter: wait weeks for a review. > > > > > > > review: clean up a and b > > > > > > > submitter: drop everything in life to try to rebase 1 hour > > > > > > > reviewer: one day later ow hey one more comment on //59 > > > > > > > Now its done again > > > > > > > > > > > > > > Now its 7 hours later > > > > > > > > > > > > > > Now the build is broken again > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-8177/7/artifact/out/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-nodemanager.txt > > > > > > > > > > > > > > Now Its friday night > > > > > > > Now its gonna probably wait till monday or worse. > > > > > > > > > > > > > > This isnt a "skill" its like an episode of the office. > > > > > > > > > > > > > > > > > > > > > On Fri, Mar 20, 2026 at 3:45 PM larry mccay <[email protected] > > > > > > wrote: > > > > > > > > > > > > > >> +1 on closing them. > > > > > > >> I would do it based on updated dates. > > > > > > >> If there is no movement in a given period then close it. > > > > > > >> > > > > > > >> As far as committers being in the business of cleaning up > > > > > > contributions, I > > > > > > >> am mostly against this. > > > > > > >> Contributors learn proper skills by getting things in - not be > > > > others > > > > > > >> doing > > > > > > >> it for them. > > > > > > >> It can be painful but such is growth. > > > > > > >> > > > > > > >> Projects can add linting to remove the burden of the > frustration > > > and > > > > > the > > > > > > >> need to review nit-picky things which would go a long way. > > > > > > >> > > > > > > >> On Fri, Mar 20, 2026 at 3:02 PM Aaron Fabbri < > > [email protected]> > > > > > > wrote: > > > > > > >> > > > > > > >> > On Thu, Mar 19, 2026 at 10:38 PM Ayush Saxena < > > > [email protected] > > > > > > > > > > > >> wrote: > > > > > > >> > > > > > > > >> > > I’m not particularly in favor of this activity, but I > won’t > > > > stand > > > > > in > > > > > > >> > > the way if there is sufficient agreement to move forward > > with > > > > it. > > > > > > >> > > > > > > > > >> > > > > > > > > >> > Hi Ayush! Thanks for the input. Fair points. > > > > > > >> > > > > > > > >> > I'll note we do have a bot to resolve stale PRs. I've seen > > > similar > > > > > > >> worflows > > > > > > >> > work well for issues, perhaps with a label/tag when we want > to > > > > > > override > > > > > > >> > cleanup and keep an issue open. > > > > > > >> > > > > > > > >> > > > > > > > >> > > From my perspective, if something is identified as an > issue, > > > it > > > > > > should > > > > > > >> > > remain open until one of the following happens: it is > > > resolved, > > > > it > > > > > > is > > > > > > >> > > determined not to be an issue, or we consciously decide to > > > drop > > > > it > > > > > > due > > > > > > >> > > to technical limitations. Closing an issue simply because > it > > > > > hasn’t > > > > > > >> > > been addressed within a certain arbitrary timeframe > doesn’t > > > feel > > > > > > like > > > > > > >> > > the right approach. > > > > > > >> > > > > > > > > >> > > > > > > > >> > In an ideal world, I agree. I'm being pragmatic in realizing > > > that > > > > > > >> nobody is > > > > > > >> > going to take the time to dig through the code and see if > > > ancient > > > > > > issues > > > > > > >> > still apply. Some of these are just old, e.g a bug against > > > 0.6.1, > > > > > > >> > HADOOP-743 > > > > > > >> > < > > > https://issues.apache.org/jira/browse/HADOOP-743?filter=12354400 > > > > >. > > > > > > If > > > > > > >> > this > > > > > > >> > project gets a sudden influx of new developers maybe we > could > > > > tackle > > > > > > it, > > > > > > >> > but today we're struggling to keep up. Some of these are > > really > > > > > > >> > time-consuming to re-test and see if they still apply (at > > least > > > > for > > > > > > me, > > > > > > >> > without context on the entire codebase). > > > > > > >> > But you have a good point, say, for a critical bug. Another > > idea > > > > > would > > > > > > >> be > > > > > > >> > to filter by severity. > > > > > > >> > > > > > > > >> > Open to your suggestions. This filter sorts by oldest > Created: > > > > link > > > > > > >> > < > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/issues/?filter=12354400&jql=project%20%3D%20HADOOP%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC > > > > > > >> > > > > > > > > >> > How about if I ping the Jira asking if it is still valid, > and > > > if I > > > > > get > > > > > > >> no > > > > > > >> > response, resolve it? > > > > > > >> > > > > > > > >> > So, instead of a bulk action, we just spend some time > > resolving > > > > > these > > > > > > >> > oldest issues one-by-one? I'm happy as long as we can make > > some > > > > > steady > > > > > > >> > progress. > > > > > > >> > For serious bugs, we could lean towards not resolving them. > > For > > > > > random > > > > > > >> > "wishlist" items people have created over the years, IMO, we > > > > should > > > > > > >> resolve > > > > > > >> > them (e.g. HADOOP-1257 > > > > > > >> > < > > > > https://issues.apache.org/jira/browse/HADOOP-1257?filter=12354400> > > > > > > and > > > > > > >> > HADOOP-1307 > > > > > > >> > < > > > > https://issues.apache.org/jira/browse/HADOOP-1307?filter=12354400 > > > > > >) > > > > > > >> > > > > > > > >> > Let me know what you think. > > > > > > >> > Thanks > > > > > > >> > Aaron > > > > > > >> > > > > > > > >> > > > > > > > >> > > -Ayush > > > > > > >> > > > > > > > > >> > > On Fri, 20 Mar 2026 at 10:49, Cheng Pan < > [email protected]> > > > > > wrote: > > > > > > >> > > > > > > > > > >> > > > Hi Aaron, > > > > > > >> > > > > > > > > > >> > > > The condition `updated < 120m` seems incorrect, I use > > your > > > > > query > > > > > > it > > > > > > >> > > returns 2970 tickets, but if I replace it with `updated < > > > > > > >> '2016-01-01'`, > > > > > > >> > > only 857 results. > > > > > > >> > > > > > > > > > >> > > > And I am neutral for bulk closing, since I see neither > > much > > > > > > benefit > > > > > > >> nor > > > > > > >> > > any harm. > > > > > > >> > > > > > > > > > >> > > > Thanks, > > > > > > >> > > > Cheng Pan > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > On Mar 20, 2026, at 00:21, Aaron Fabbri < > > > [email protected] > > > > > > > > > > > >> wrote: > > > > > > >> > > > > > > > > > > >> > > > > Hi everyone, > > > > > > >> > > > > > > > > > > >> > > > > I'm going through our issue backlog and noticing we > > have a > > > > lot > > > > > > of > > > > > > >> old > > > > > > >> > > > > issues. > > > > > > >> > > > > > > > > > > >> > > > > E.g. This filter for issues not updated for 10 years > > > > > > >> > > > > < > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20HADOOP%20AND%20resolution%20%3D%20Unresolved%20AND%20updated%20%20%3C%20120m%20ORDER%20BY%20updated%20ASC > > > > > > >> > > > > > > > > > >> > > > > has > > > > > > >> > > > > almost 3000 results. > > > > > > >> > > > > > > > > > > >> > > > > How do people feel about me doing a bulk resolution > with > > > > > > >> "Abandoned"? > > > > > > >> > > I'd > > > > > > >> > > > > add a note saying this issue hasn't been updated for > 10 > > > > years, > > > > > > >> reopen > > > > > > >> > > and > > > > > > >> > > > > update if needed. > > > > > > >> > > > > > > > > > > >> > > > > Thanks! > > > > > > >> > > > > Aaron > > > > > > >> > > > > > > > > > > >> > > > > On Thu, Mar 19, 2026 at 9:18 AM Aaron Fabbri < > > > > > > [email protected]> > > > > > > >> > > wrote: > > > > > > >> > > > > > > > > > > >> > > > >> Hi Wei-Chiu, > > > > > > >> > > > >> Thanks for the feedback. I will resend on common-dev > > > list. > > > > > > >> > > > >> Cheers, > > > > > > >> > > > >> Aaron > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > > >> > > > >> On Wed, Mar 18, 2026 at 9:35 PM Wei-Chiu Chuang < > > > > > > >> [email protected] > > > > > > >> > > > > > > > > >> > > > >> wrote: > > > > > > >> > > > >> > > > > > > >> > > > >>> +1 > > > > > > >> > > > >>> > > > > > > >> > > > >>> And I mean, this matter is better discussed in dev > > > mailing > > > > > > >> lists. > > > > > > >> > > > >>> > > > > > > >> > > > >>> On Wed, Mar 18, 2026 at 5:33 PM Aaron Fabbri < > > > > > > [email protected] > > > > > > >> > > > > > > > >> > > wrote: > > > > > > >> > > > >>> > > > > > > >> > > > >>> <snip> pasted above </snip> > > > > > > >> > > > >>> > > > > > > >> > > > >>> > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > --------------------------------------------------------------------- > > > > > > >> > > > To unsubscribe, e-mail: > > > > > [email protected] > > > > > > >> > > > For additional commands, e-mail: > > > > > > [email protected] > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > --------------------------------------------------------------------- > > > > > > >> > > To unsubscribe, e-mail: > > > > [email protected] > > > > > > >> > > For additional commands, e-mail: > > > > > [email protected] > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
