I do not want to derail the conversation but can we discuss this:: https://github.com/apache/hadoop/pull/8177
" [image: @cnauroth] * cnauroth <https://github.com/cnauroth> * 4 days ago <https://github.com/apache/hadoop/pull/8177#discussion_r2941946178> Considering this is now replaced with serialized_passwd on line 95, let's delete this line instead of commenting it out. I dont want to beat an old drum. But I see a few ways projects handle this. When I was involved with hive people would kick-back the PR over the tiny junk. It would result in a situation like above. A single comment creates a 4 day back and forth. I can point to you some very very frustrating examples of how I "finished" things 10 times and had to wait days/weeks for reviews. I understand that we dont want to push tons of cleanup work on the committers. "submiter forgot the licence header, and these files are indented wrong" That is too much for the committer to clean up. The committer shouldn't be responsible for massive cleanups. But in the interest of sanity, "committed with small fixes" would be a lot better work-flow. I have seen the Cassandra folks do this, I did this with the "gossip" podling. This is a little chippy thing, of course I want to follow all the code standards, but lets look at this critically. There probably isn't a c-linter inside this project, and even if there is the clinter doesn't seem to block the build. So why create a 4 day turn around for a single comment? Since there is no "chat room" and everyone is working async, the average turn around time for a chippy comment is like 4 days. On Fri, Mar 20, 2026 at 1:38 AM 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. > > 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. > > -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] > >
