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