> I think that there might be legitimate cases when a PR is up just for > extended periods of time because it depends on other functionality or it is > just worked on for such a long time, If something has 0 discussion, movement, or code changes for 6 months I think it's probably safe to close it out. In the odd chance there's something that's just lying dormant blocked on another dependency people can re-open it / we can cross that bridge when the time comes and add some kind of exemption to the automation.
On Tue, Apr 15, 2025, at 7:56 AM, Paulo Motta wrote: > > 3) having e.g. a GitHub trigger which would scan commit message when it is > > merged, extracting JIRA ticket number and then go to GitHub and close > > respective PRs. > > This is implementation detail, but I don't think that scanning the commit > message on merge would be needed. When a PR is opened with a JIRA# then it's > already associated with that JIRA by INFRA automation. This would be the > "opposite" operation: close the PRs associated with a JIRA when the JIRA > ticket itself is resolved (not withrdrawn for example). So for example, if > you associate an open PR to a JIRA then it could be theoretically closed, > even if the PR doesnt have the JIRA# in the PR title, even though I'm not > sure this would be desired. > > On Tue, 15 Apr 2025 at 07:47 Paulo Motta <pa...@apache.org> wrote: >> Just to clarify option 3), I'm not sure ASF INFRA currently provides the >> ability of auto-closing PRs associated with a JIRA, this would be a feature >> request that would obviously need to be triaged and prioritized at their >> pace. >> >> Assuming this is a feasible and reasonable request, then I'd suggest we use >> the manual approach 1) on the meantime. >> >> Another clarifying point is that this still requires that the jira # is >> added to the PR, which is already done and would not be inconvenient IMO >> since it's already part of the workflow. >> >> On Tue, 15 Apr 2025 at 02:47 Štefan Miklošovič <smikloso...@apache.org> >> wrote: >>> Thanks Paulo, I have not known that one. >>> >>> Jordan, yes I agree. I think that unless we automate it it is more about >>> discipline than anything else. If I briefly enumerate the options: >>> >>> 1) put here "closes" as Paulo suggested - that needs manual intervention >>> for a committer to put there such message (if I understood that right) >>> 2) specifying JIRA ticket number in PR title - manual intervention required >>> 3) having e.g. a GitHub trigger which would scan commit message when it is >>> merged, extracting JIRA ticket number and then go to GitHub and close >>> respective PRs. This requires two manual interventions - somebody has to >>> write a JIRA ticket number in the commit message - this happens almost all >>> the time anyway and it is pretty much internalized by committers already so >>> I don't think this is inconvenient. Plus somebody has to make titles in PRs >>> - manual again to connect JIRA ticket with a PR. Or maybe it would scan >>> names of branches of PRs? That might work in the majority of cases but >>> again, some people do not name them CASSANDRA-123 but like feature/c123 or >>> something like that. Again not something which is consistent everywhere. >>> >>> After what Paulo suggested, I don't mind starting to do it like that. We >>> might "vote" on having to close it like Paulo suggested in each PR. That >>> would resolve the majority of cases. It would not resolve it if we put >>> "closes" into the commit message just for the very first commit for >>> multi-branch patches when merging up while we have multiple PRs opened. We >>> would either be required to enumerate all such PRs (multiple "closes") or >>> one "close" per branch. >>> >>> But we would need to make this a policy we all agree on and follow >>> otherwise we will be where we are now. >>> >>> Bernardo: >>> >>> Could you please at last make the window of what is stale wider? E.g. one >>> year? I think that there might be legitimate cases when a PR is up just for >>> extended periods of time because it depends on other functionality or it is >>> just worked on for such a long time, yes. One year is just fine. We do not >>> want to close stuff prematurely when people still work on it, 6 months >>> seems too short. >>> >>> On Tue, Apr 15, 2025 at 4:09 AM Bernardo Botella >>> <conta...@bernardobotella.com> wrote: >>>> +1 on Paulo’s proposal. That will definitely help things up. >>>> >>>> I will give one or two more days in case someone missed the thread, and if >>>> there is no voices against it, I’ll just close the stale PRs and raise the >>>> ticket to INFRA to close PRs when a Jira ticket is resolved. >>>> >>>> Bernardo >>>> >>>>> On Apr 14, 2025, at 4:56 PM, Jordan West <jw...@apache.org> wrote: >>>>> >>>>> If we want something to happen repeatably we should automate it not add >>>>> more manual tasks to the list. Paulo’s suggestion seems to be in line >>>>> with that so +1 to something in that direction. >>>>> >>>>> We continually are swimming upstream making up our own process. The ask >>>>> to put the ticket number in the PR title requires manual effort because >>>>> by default GitHub takes the top line of the commit message which we >>>>> explicitly say shouldn’t contain the JIRA (that goes in the second line). >>>>> Until we have a solution it’s reasonable to ask folks to make that manual >>>>> change but we should also accept folks will forget or won’t do it because >>>>> we asked them to remember yet another manual step. >>>>> >>>>> Jordan >>>>> >>>>> >>>>> On Mon, Apr 14, 2025 at 09:17 Paulo Motta <pa...@apache.org> wrote: >>>>>> *committers (and not reviewers) >>>>>> >>>>>> On Mon, Apr 14, 2025 at 12:13 PM Paulo Motta <pa...@apache.org> wrote: >>>>>>> > I am not sure why it is so hard for people to not forget to close a >>>>>>> > PR when their branch is merged. >>>>>>> >>>>>>> I wonder if reviewers* know they need to append the message "Closes >>>>>>> #PR_ID" to the end of the commit message to have the PR be closed, this >>>>>>> does not seem very obvious, but it's also a bit inconvenient. >>>>>>> >>>>>>> >>>>>>> Since Apache INFRA already links github PRs to the appropriate JIRA, it >>>>>>> would probably not be very hard to have the PR be closed when the JIRA >>>>>>> is resolved. If this does not sound stupid perhaps we could submit an >>>>>>> INFRA feature request to address this issue. >>>>>>> >>>>>>> On Mon, Apr 14, 2025 at 3:17 AM Štefan Miklošovič >>>>>>> <smikloso...@apache.org> wrote: >>>>>>>> I am not sure why it is so hard for people to not forget to close a PR >>>>>>>> when their branch is merged. I stopped "fighting" this and I just run >>>>>>>> a script every few weeks. Funny that people don't forget to create a >>>>>>>> PR when trying to make a change but as soon as it is delivered the >>>>>>>> respective PR is "memory holed". A PR does not close itself if it was >>>>>>>> not obvious already. >>>>>>>> >>>>>>>> On Mon, Apr 14, 2025 at 8:00 AM Bernardo Botella >>>>>>>> <conta...@bernardobotella.com> wrote: >>>>>>>>> Thanks Josh and Stefan for the comments! >>>>>>>>> >>>>>>>>> Such a script can definitely be helpful for this purpose of keeping >>>>>>>>> our house tidy. It seems that the thread hasn’t gotten much steam >>>>>>>>> yet. As this is, by no means, any urgent matter, let’s give some more >>>>>>>>> time for people to pitch in. I’ll wait some more days looking for >>>>>>>>> answers on this thread. Then, if no one has any strong opinion >>>>>>>>> against it, I can start closing old PRs. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Bernardo >>>>>>>>> >>>>>>>>>> On Apr 11, 2025, at 10:22 AM, Štefan Miklošovič >>>>>>>>>> <smikloso...@apache.org> wrote: >>>>>>>>>> >>>>>>>>>> I have a small script which scans GH pull requests (their titles) >>>>>>>>>> and looks into JIRA to see what is their status. When it is >>>>>>>>>> "resolved" it prints it to the console. Then I go over the links of >>>>>>>>>> PRs and close them one by one. This relies on the title of the PR to >>>>>>>>>> be in exact format (CASSANDRA-123 a title of the ticket) and not >>>>>>>>>> bullet proof but I have not come up with anything better so far. >>>>>>>>>> >>>>>>>>>> On Fri, Apr 11, 2025 at 5:19 PM Josh McKenzie <jmcken...@apache.org> >>>>>>>>>> wrote: >>>>>>>>>>> __ >>>>>>>>>>> +1 from me. >>>>>>>>>>> >>>>>>>>>>> My intuition is that this is a logical consequence of us not using >>>>>>>>>>> github to merge PR's so they don't auto-close. Which seems like >>>>>>>>>>> it's a logical consequence of us using merge commits instead of >>>>>>>>>>> per-branch commits of patches. >>>>>>>>>>> >>>>>>>>>>> The band-aid of at least having a human-in-the-loop to close out >>>>>>>>>>> old inactive things is better than the status quo; the information >>>>>>>>>>> is all still available in github but the status of the PR's will >>>>>>>>>>> communicate different things. >>>>>>>>>>> >>>>>>>>>>> On Thu, Apr 10, 2025, at 7:14 PM, Bernardo Botella wrote: >>>>>>>>>>>> Hi everyone! >>>>>>>>>>>> >>>>>>>>>>>> First of all, this may have come out before, and I understand it >>>>>>>>>>>> is really hard to keep a tidy house with so many different >>>>>>>>>>>> collaborations. But, I can't help the feeling that coming to the >>>>>>>>>>>> main Apache Cassandra repository and seeing more than 600 open >>>>>>>>>>>> PRs, some of them without activity for 5+ years, gives the wrong >>>>>>>>>>>> impression about the love and care that we all share for this code >>>>>>>>>>>> base. I think we can find an easy to follow agreement to try and >>>>>>>>>>>> keep things a bit tidier. I wanted to propose some kind of "rule" >>>>>>>>>>>> that allow us to directly close PRs that haven't had activity in a >>>>>>>>>>>> reasonable and conservative amount of time of, let's say, 6 >>>>>>>>>>>> months? I want to reiterate that I mean no activity at all for six >>>>>>>>>>>> months from the PR author. I understand that complex PRs can be >>>>>>>>>>>> opened for longer than that period, and that's perfectly fine. >>>>>>>>>>>> >>>>>>>>>>>> What do you all think? >>>>>>>>>>>> >>>>>>>>>>>> Bernardo >>>>>>>>>>>
