Update maintainer documentation. #5724
Conversation
- Fix Markdown format - Note Linux in the mission statement - Update the maintainer guidelines based on current state - Loosen the new maintainer expectations - Clarify what things the PLC should be added to - Add documentation for making a new Homebrew release
Co-Authored-By: MikeMcQuaid <mike@mikemcquaid.com>
|
|
||
| Homebrew is about Unix software. Stuff that builds to an `.app` should | ||
| probably be in Homebrew Cask instead. | ||
| be in Homebrew Cask instead. |
There was a problem hiding this comment.
Regarding this change, I’ve been thinking of mpv recently (formula, cask). The formula builds a .app, and according to the analytics it is almost ten times as popular as the cask. In addition, the cask uses the builds made not by the team, but a user that they trust (and link to directly and officially in the page).
Due to this, I have been considering removing the cask (I’m informally trying to query people to see how disruptive it is for their use of mpv that he app bundle is in a versioned directory in Cellar instead of /Applications). Does the removal of probably mean we should remove the formula instead?
There was a problem hiding this comment.
Does the removal of
probablymean we should remove the formula instead?
We shouldn't remove the formula but we should remove the .app that the formula builds. In general where something is useful on the command-line the formula should remain and the Cask be the "GUI install". How's that sound?
There was a problem hiding this comment.
Apologies for the length of the reply. I did try making it shorter. Maybe I should open an issue for discussion.
We shouldn't remove the formula but we should remove the
.appthat the formula builds.
I’m guessing the mpv formula includes the app because --with-bundle was popular. So removing the bundle will make users open issues.
To clarify, I like the formula (I use it instead of the cask) and think there is value to some formulae building .apps — cases where the dev team does not have someone in charge of making the bundles. For example, in Cask we are some versions behind on Inkscape (fun fact: also part of the SFC) because they have no macOS devs.
I’d be fine with removing those casks in favour of the formulae counterparts, as I think users would be better served when the alternative is having older software. But the brew/brew cask division is confusing for users and separating by CLI/GUI makes sense, so maybe app-building-formulae should be restricted to third party taps. To push the point further, maybe CLI-only casks (closed-source) should be removed as well.
But the cask can also install the CLI. I’m open to removing that line, but I guess some users would be unhappy to have to brew install mpv && brew cask install mpv to get both the CLI and the GUI versions. It would help bring home the HB is CLI and HBC is GUI point, but might it also cause problems stemming from different installed versions of the CLI and GUI? That makes me ambivalent to removing the binary stanza from the cask.
But otherwise, if you do think app bundles should be removed from formulae, the rule would be “if want the CLI, brew, if you want the GUI, brew cask but it would also bring the CLI that typically comes in the package”.
Some casks tried to make that clearer (mkvtoolnix) by adding an -app suffix, but that’s confusing even to maintainers. That suffix was added in the spirit of deduplication, but now we should probably get rid of that rule and rename those casks.
There was a problem hiding this comment.
For context, right now in homebrew-core there are at least 33 formulae that build apps:
There was a problem hiding this comment.
Maybe I should open an issue for discussion.
Yeh, good idea. I've replied inline to your comment but would be good to move future conversation to one.
To clarify, I like the formula (I use it instead of the cask) and think there is value to some formulae building
.apps — cases where the dev team does not have someone in charge of making the bundles.
The problem with formulae building apps is the way Homebrew handles apps is a mess. We removed the brew linkapps commands for this reason and generally application bundles that are created are not "real" i.e. relocatable or including their dependencies. It's a shitty experience, basically.
For example, in Cask we are some versions behind on Inkscape (fun fact: also part of the SFC) because they have no macOS devs.
Yeh, I'm aware of this. To me this does seem fairly similar to the days of when we weren't favouring X11, required Clang, etc. in that we're partly acting as a forcing function to produce a better macOS ecosystem. We should make it easier to package well-packaged macOS applications than the opposite.
I’d be fine with removing those casks in favour of the formulae counterparts, as I think users would be better served when the alternative is having older software. But the
brew/brew caskdivision is confusing for users and separating by CLI/GUI makes sense, so maybeapp-building-formulae should be restricted to third party taps. To push the point further, maybe CLI-only casks (closed-source) should be removed as well.
I really don't want to remove even older GUI Casks that build .apps in favour of formulae. Inkscape is a great example, actually, because the formula was a nightmare to keep building successfully and it had generally a long, painful build process and also that I'm not convinced older versions so old as to be "useless" (despite what others may claim).
But the
brew/brew caskdivision is confusing for users and separating by CLI/GUI makes sense, so maybeapp-building-formulae should be restricted to third party taps.
I'd be in favour of this if we're also going to nudge towards Casks. Something we've talked about in the past that may be worth resurrecting is somehow having a formulae tap that's designed to build and upload files that can be then used as casks.
To push the point further, maybe CLI-only casks (closed-source) should be removed as well.
Are there many CLI-only closed-source casks? I'd be interested in thinking more about this. It'd be worth using analytics data to inform this and other decisions (https://formulae.brew.sh/analytics/cask-install/30d/)
But the cask can also install the CLI. I’m open to removing that line, but I guess some users would be unhappy to have to
brew install mpv && brew cask install mpvto get both the CLI and the GUI versions.
Yes, I agree. I think it's fine for the Cask to install a CLI link if it's already included with the software.
But otherwise, if you do think app bundles should be removed from formulae, the rule would be “if want the CLI,
brew, if you want the GUI,brew caskbut it would also bring the CLI that typically comes in the package”.
Yes, this seems reasonable.
Some casks tried to make that clearer (
mkvtoolnix) by adding an-appsuffix, but that’s confusing even to maintainers. That suffix was added in the spirit of deduplication, but now we should probably get rid of that rule and rename those casks.
Yes, agreed.
It's also worth noting that I don't think these requirements changing here state would should be done immediately to all existing formulae/casks but should be enforced pretty strongly for new formulae and casks.
Something that always rings in my ears is what @mxcl said about Homebrew's primary purpose being "to be useful". In my Homebrew I've slightly extended that to be "to be useful at a quality that minimises support issues and improves the macOS ecosystem". I think that's what I'd like to keep in mind when we're thinking about this stuff.
There was a problem hiding this comment.
Are there many CLI-only closed-source casks? I'd be interested in thinking more about this. It'd be worth using analytics data to inform this and other decisions
CC @Homebrew/maintainers for thoughts.