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