workflows: notify on autobump bypass

[iMichka]

I am unsure how often this is happening. We do not want maintainers (or others) manually bumping things before the bot does, as this feels useless.

This is a non-blocking step: the PR can still be merged, we just give gentel nudge in the right direction

• [ ] Have you followed the guidelines for contributing?
• [ ] Have you ensured that your commits follow the commit style guide?
• [ ] Have you checked that there aren't other open pull requests for the same formula update/change?
• [ ] Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• [ ] Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• [ ] Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[iMichka]

Here is an example of output message when run on my fork: https://github.com/iMichka/homebrew-core/pull/2#issuecomment-1942493304

[iMichka]

Please also take into account that I have another change in my mind, that is very similar to this one, and I would like to do a follow-up pull request: for any other brew bump-formula-pr usage, I would like to display a message that nudges contributors and maintainers towards adding packages to autobump instead of doing stuff manually.

So either everything goes into GitHub comments like I did here, or the logic goes into the brew bump-formula-pr command (and we add a bypass flag for testbot and people who really know what they are doing).

[iMichka]

2 examples today, as suspected: https://github.com/Homebrew/homebrew-core/pull/162822 https://github.com/Homebrew/homebrew-core/pull/162825

[iMichka]

Let's discuss the strategy in https://github.com/Homebrew/actions/issues/337, as this issue looks similar.

[Bo98]

Maybe worth stepping back one step and clarifying what the problem we're solving here is, because I think I might have misunderstood something here.

Sure people bumping things that are autobumped is perhaps unnecessary, but I also don't think it's necessarily a "problem" unless those users are creating bad PRs? The examples you linked are perfectly good PRs that were merged, even if they weren't necessary. I'm asking because it seems like we're putting in effort to implement this, so it would be good to document what we're looking to gain from this.

[iMichka]

Makes sense, let me explain what I have in mind.

Of course we merged all these PRs. Because nothing got broken and they did not cause any "technical" issue.

It's more a mindset thing: when someone (a contributor, a maintainer) connects to GitHub / interacts with the project, I would like them to think on how they can focus their time on actually fixing broken things, instead of running "brew livecheck / brew bump-pr" each day (even if they have a script for that).

It might not seem a lot, but it's a few minutes per day * 365 days. I am worried about:

• maintainer / contributor burnout: their live will revolve around opening as many pull requests as possible, trying to beat the bot ... that sounds like a pretty dull activity that does not have high value for the project
• some people might use this to "fill" their GitHub history to look active ... that's also low value work that should not be rewarded

I think this is not what we expect from contributors or maintainers.

[SMillerDev]

For me it's mostly about this part of the Maintainer invite:

We would like to invite you to have commit access and be a Homebrew maintainer. If you agree to be a maintainer, you should spend a significant proportion of the time you are working on Homebrew applying and self-merging widely used changes (e.g. version updates), triaging, fixing and debugging user-reported issues, or reviewing user pull requests.

The role of a maintainer, in my view, is someone who reviews if code is up to the Homebrew standards. Not someone who does what BrewTestBot also does.

Additionally, any PR made by a maintainer is a PR that that maintainer can't review. So if we force everyone to delegate mass bumps to TestBot, we have more people who can review PRs.

Additionally additionally, it also stops the quarterly people from discovering the brew bump command, firing off 200 PRs and never responding om them again.

[Bo98]

Thanks! To be clear: I'm not trying to block things here, just trying to figure out the direction.

For me it's mostly about this part of the Maintainer invite

Is this an ongoing concern of maintainers doing this bumping? For non-maintainer contributors, we shouldn't hold them to maintainer guidelines, particularly maintainer invites they've not been sent, and contributors is what I was initially under the impression this was directed towards.

It's more a mindset thing: when someone (a contributor, a maintainer) connects to GitHub / interacts with the project, I would like them to think on how they can focus their time on actually fixing broken things, instead of running "brew livecheck / brew bump-pr" each day (even if they have a script for that).

Ok this is a bit clearer where you're coming from. Though we should be cautious we're not turning away contributors completely - some people actually prefer doing "trivial" stuff as their first contribution rather than working on technical debt like broken stuff. It's why when you see a repository blow up in popularity that you then see a ton of typo fix or README edit PRs. Sure some might be point scoring, but you shouldn't assume that from everyone. I imagine a number of current Homebrew maintainers got into Homebrew starting from a trivial bump PR or something.

Generally speaking I'm in the camp of giving guidance before the work but accepting any work already done or if they really want to do it anyway (if said work is good, of course).

Obviously, maintainers should be held to a higher standard however.

• maintainer / contributor burnout: their live will revolve around opening as many pull requests as possible, trying to beat the bot ... that sounds like a pretty dull activity that does not have high value for the project
• some people might use this to "fill" their GitHub history to look active ... that's also low value work that should not be rewarded

Both of these are worded like it's intentional acts. If a non-maintainer contributor is actively and knowingly trying to beat the bot then that's really their concern. If a maintainer is doing so however, then that's different and we should talk about that.

[SMillerDev]

we shouldn't hold them to maintainer guidelines, and contributors is what I was initially under the impression this was directed towards.

The reason I brought it up was more maintainers autobumping outside of TestBot then contributors. But my "additionally additionally" also indicates the problem with contributors that this would fix.

[Bo98]

Ok interesting to know maintainers are doing this a lot. Is this through automated mass bumping or manual bumping? Can we tweak/standardise the tools people use to identify things to bump, e.g. adjust brew livecheck to indicate they don't need to be bumped? Maybe even exclude autobumped packages entirely from tap-wide brew livecheck runs unless explicitly opted in.

I'm guessing an issue for people is knowing which formulae are auto bumped - most won't by heart and I don't expect many people to be reading a random file in .github. Only knowing after the bump is also a bit late - if there's multiple of them then they probably won't even remember them all for next time and potentially just give up contributing entirely.

[iMichka]

Ok interesting to know maintainers are doing this a lot.

I would not say all of them, and not all the time. Sometimes a new maintainer errs on that side, and we have to educate them. Sometimes a few bumps are done "by mistake" because they did not keep their livecheck / bump script up to date.

I have opened an alternative PR that should solve the "auto bump" situation: https://github.com/Homebrew/brew/pull/16750

[iMichka]

Though we should be cautious we're not turning away contributors completely - some people actually prefer doing "trivial" stuff as their first contribution rather than working on technical debt like broken stuff.

Agreed: reducing the functionality of "brew bump-..." tooling is quite a huge shift in paradim, and I am aware of this. We have been really proud over the years to say to everyone: "look how easy it is to bump a package in homebrew".

But I think things have changed: we have more packages than ever, and we have added automation to cover this use case. It will be harder for "randoms" to just bump a package ... but most of them never became maintainers anyway so I do not think we are losing a lot here.

[p-linnane]

maintainers autobumping outside of TestBot then contributors

Since our discussion at this year's AGM, I have seen much less of this and more formulae being added to autobump.txtby maintainers. I also think maintainer actions can be handled via dialog that will have an impact one way or another.

I imagine a number of current Homebrew maintainers got into Homebrew starting from a trivial bump PR or something

Here's mine: https://github.com/Homebrew/homebrew-cask/pull/124138. I created my GitHub account to open it because it had been broken. I do a few more things than version bumps now, but it was what got me interested and most of my early contributions were straight version bumps. I just kind of completely fell down the Homebrew rabbit hole from there since I was enjoying it. Speaking for myself, if I was told "this is a community driven project" and then "don't open PR's cus our bot does it", I don't think I would've cared to keep contributing.

[bevanjkay]

One other consideration I have is that we do not include every formula/cask in the autobump list, so if the way we deal with this discourages users from using brew bump* at all, then what happens to the everything that isn't included in autobump?

I do think that there's an issue when a contributor may have too many PRs open OR they are unresponsive to fixing issues that arise in their PRs, but is there actually a concern with contributors manually bumping if they happen to get to it before autobump? A majority of our issues come from users that are too overzealous about this process, which could hopefully be solved by asking them to slow down.

[timsutton]

I will say that as a new maintainer – and also someone susceptible to compulsive "automate all the things" behaviour – I enjoyed using brew bump --open-pr as an onramp to contributing. Of course, then I realized there's always new formula breakage to learn to fix!

My gut reaction is that it makes sense to continually add more "easy" bumps to autobump.txt. autobump.txt contains only 25% of the total formulae, so to me that still leaves a lot of room for individuals' contributions? I don't have experience with adding to autobump.txt yet, but is that usually done just via "Hey, I noticed this formula and it seems like we shouldn't have to be bumping it ourselves" kind of thing?

Maybe this just has to do with "should it be dead easy for a first-time contributor to get their PR landed, or should we expect they may need to do a bit of legwork on figuring out how to fix up a formula that's failing CI when trying to bump, but we'll support them through that?"

[SMillerDev]

The goal is never to block people from using brew bump. Only people who bump a lot of things should be affected by this.

So we still want people to get into contributing the same way you did, but if they script it all are they really still contributing.

[MikeMcQuaid]

The goal is never to block people from using brew bump. Only people who bump a lot of things should be affected by this.

So we still want people to get into contributing the same way you did, but if they script it all are they really still contributing.

Agreed. Adding things to autobump lists should be a good contribution itself. We should perhaps provide better contribution docs so people can suggest adding things there.

[iMichka]

Replaced by https://github.com/Homebrew/brew/pull/16750