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