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