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