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