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