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