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