Consider moving into Homebrew GitHub organisation

[MikeMcQuaid]

• [x] None of the templates was appropriate for my issue, or I’m not sure.

I think the Homebrew/brew merge of brew cask code has been a massive success. I'd like to propose that you consider moving caskroom/homebrew-cask into Homebrew/homebrew-cask. I think this would help unify the projects and communities a little bit more and generally strengthen both projects.

I think it would be cool to also consider moving the other taps over, too. The only problem is a naming collision with caskroom/homebrew-versions and Homebrew/homebrew-versions but I'd also propose considering the addition of the versioned casks into caskroom/homebrew-cask (this would also be consistent with homebrew/homebrew-core).

Thoughts? Concerns? Feelings?

[wickles]

Regarding collisions, it should be noted that there is still some duplication/overlap between some homebrew formulae and casks (see https://github.com/caskroom/homebrew-cask/issues/15603). In particular: emacs, macvim, wireshark, mono/mono-mdk, djview4/djview, etc

[commitay]

@wickles Most are intentional duplicates. From the issue you linked: https://github.com/caskroom/homebrew-cask/issues/15603#issuecomment-271920038

mono / mono-mdk are very different in how and what they install, the mono formula would require extensive changes* to replace mono-mdk and we would still need to somehow provide compatibility for Casks that require mono and expect it to reside in /Library/Frameworks.

The purpose of this issue at this stage is to discuss if we should move, please keep comments on topic or it will be locked.

*Edit for clarity: I'm not sure if it is possible to build the complete mono-mdk from source.

[reitermarkus]

I‘m definitely in favour of this. Just not sure what would be the best place to start with. Probably allowing versioned Casks in caskroom/versions, i.e. allowing @ in tokens.

[commitay]

I don't really have an opinion either way with regards to moving.

Personally I would oppose splitting up the taps between different organisations, so I think if we do move, we should move all of the taps.

Moving Casks from versions into the main tap would be something I am against, I find it easier to manage and maintain "versions" when they are separated from the main repo.

One potential issue is the impact the Cask repos will have on the overall Homebrew build queue for Travis CI. Builds are queued per organisation, so our traffic will delay builds in Homebrew/brew and the other Homebrew repos that use Travis.

[MikeMcQuaid]

Personally I would oppose splitting up the taps between different organisations, so I think if we do move, we should move all of the taps.

Moving Casks from versions into the main tap would be something I am against, I find it easier to manage and maintain "versions" when they are separated from the main repo.

Unfortunately these are contradictory desires, hopefully as I explained above (I'll happily elaborate if not, though).

One potential issue is the impact the Cask repos will have on the overall Homebrew build queue for Travis CI. Builds are queued per organisation, so our traffic will delay builds in Homebrew/brew and the other Homebrew repos that use Travis.

Homebrew is fine with this 👍

[vitorgalvao]

I’m still thinking about this, and had been waiting for some other opinions first. This is partly to me not immediately seeing a great benefit either way.

I'll happily elaborate if not, though

Could you, please? Why is there a contradiction?

I agree with @commitay. Having versions in a separate repo is to me a clear win in our case. Many of our versioned casks are more than old versions of casks in the main repo. We have a lot of nightly/canary/… that are encouraged to use an url do block to dynamically get the latest version, while the same is discouraged in the other repos. So they are treated differently and are up to different standards; having them in a separate tap makes sense. Having cask@nightly or cask@beta also doesn’t sound right to me (but I’m confident I could be convinced otherwise).

I also agree that to move it’d make sense to either move everything or nothing. I say this because from all the repos, the one that mostly makes sense to stay in a different organisation is the main one. I feel strongly the main repo is much more than a tap — it‘s a place for discussion of policy and documentation that affects a whole group of taps (the ones that have casks).

Formulae and casks are different things and both projects have slightly different aims. We both want to facilitate the management of software, but HB’s rules are more strict about what they allow. We all understand that due to the nature of what we install (a major difference being that HBC allows non-open-source software) it makes sense for both projects to have different rules.

Occasionally (though less frequently than before) we still get users to whom we have to explain those differences. By merging the main tap into the HB organisation, I think that will become harder to explain again. It’ll be even harder to explain why some official taps are in a different organisation.

[MikeMcQuaid]

Could you, please? Why is there a contradiction?

Homebrew/homebrew-versions already exists so Caskroom/homebrew-versions cannot be moved across (unless it gets renamed to something like Homebrew/homebrew-cask-versions).

It’ll be even harder to explain why some official taps are in a different organisation.

I agree with not doing this.

Occasionally (though less frequently than before) we still get users to whom we have to explain those differences.

I'm not sure the org name would change that if everything else remains the same. Worth noting (I'm sure everyone knows this but some readers may not) that Homebrew/brew contains all the brew cask command code at this point.

[vitorgalvao]

unless it gets renamed to something like Homebrew/homebrew-cask-versions

Couldn’t we change the core to allow taps to have a caskroom- prefix as well as a homebrew- prefix? Internally the former would be an alias to the latter, but it’d fix the conflict.

Did we discuss this idea before (I’m getting déjà vu thinking of it)? Is there a reason why it’s not feasible?

[ilovezfs]

I think there's something to be said for consistency.

brew install gcc
brew install gcc@6
brew cask install java
brew cask install caskroom/versions/java8

is the status quo.

I think it would be much nicer for users to be able to

brew install gcc
brew install gcc@6
brew cask install java
brew cask install java@8

[commitay]

Did we discuss this idea before

There was some discussion about this in the previous intergration issue https://github.com/caskroom/homebrew-cask/issues/14384

[vitorgalvao]

@ilovezfs No idea how many people actually type caskroom/versions/ every time. I think it’d be fairer to call it brew cask install java8. That said, I have no issue with java@8 (or more accurately, caskroom/versions/java@8); I do have issue with java@nightly.

Either way, that still does not take into account my argument:

Many of our versioned casks are more than old versions of casks in the main repo. We have a lot of nightly/canary/… that are encouraged to use an url do block to dynamically get the latest version, while the same is discouraged in the other repos. So they are treated differently and are up to different standards; having them in a separate tap makes sense.

That is to me way more important and more maintainable for our own case.

I’m all for more integration between the two projects, but I also think it’s the wrong approach for HBC to do something just because HB does it. It’s imperative to keep in mind that casks and formulae are not just different in terms of code. The nature of the software we allow is so different that if the rules of one project were applied to the other it’d radically change it.

We never shied away from taking for ourselves what fits from HB, but we need to have the autonomy to decide what is best for our own cases.

[vitorgalvao]

Before the discussion extends further, I’d like to ping @caskroom/maintainers. Feel free to comment or not, but some may want to at least follow the discussion and it’s easier to start sooner.

[ilovezfs]

I do have issue with java@nightly

In terms of current use and implementation @ is only valid for version numbers. So for instance, there's an audit to enforce that the unversioned formula (e.g. gcc) has a corresponding alias in the alias directory.

Josephs-MacBook-Pro:homebrew-core joe$ ls -l Aliases/gcc@7 
lrwxr-xr-x  1 joe  admin  17 Dec  9 08:31 Aliases/gcc@7 -> ../Formula/gcc.rb

That allows a user to

brew install gcc@7

So again there's a confusing inconsistency here. brew cask install java8 works but brew cask install java9 does not (yet), whereas brew install gcc@6 and brew install gcc@7 both work.

[MikeMcQuaid]

I agree with @commitay. Having versions in a separate repo is to me a clear win in our case. Many of our versioned casks are more than old versions of casks in the main repo. We have a lot of nightly/canary/… that are encouraged to use an url do block to dynamically get the latest version, while the same is discouraged in the other repos. So they are treated differently and are up to different standards; having them in a separate tap makes sense. Having cask@nightly or cask@beta also doesn’t sound right to me (but I’m confident I could be convinced otherwise).

I think it would be reasonable to exclude them, rename their repo (homebrew-cask-unversioned?) and have stuff like java@8 (that's currently really widely used and recommended by Homebrew) be part of the main repo.

Couldn’t we change the core to allow taps to have a caskroom- prefix as well as a homebrew- prefix? Internally the former would be an alias to the latter, but it’d fix the conflict.

This is technically possible but it's not a good broad change just to avoid a naming conflict.

We never shied away from taking for ourselves what fits from HB, but we need to have the autonomy to decide what is best for our own cases.

We agree here but I would say since the projects were integrated that when there's deviation it's confusing for users. As a (very) long-term thing I think it would be good if pretty much all Homebrew and Cask commands were more similar than different.

So again there's a confusing inconsistency here. brew cask install java8 works but brew cask install java9 does not (yet), whereas brew install gcc@6 and brew install gcc@7 both work.

I think this is a good point.

[commitay]

Moving the Casks from versions to Homebrew/homebrew-versions was mentioned in the previous integration issue, is that not an option?

[MikeMcQuaid]

Moving the Casks from versions to Homebrew/homebrew-versions was mentioned in the previous integration issue, is that not an option?

It's no longer an option because that repository has been deprecated and archived.

[ilovezfs]

That said, I have no issue with java@8 (or more accurately, caskroom/versions/java@8); I do have issue with java@nightly.

Would it make sense then to move all of the stuff with actual versions into the main repository using @, and rename the caskroom-versions repository to caskroom-unversioned?

That said, it does sound to me like the separate repository isn't actually needed, though, as it should be possible to treat the question of when url do is supposed to be used and when it's not supposed to be used as a matter of documentation, auditing, review, code comments, and pr templating just like anything else.

[vitorgalvao]

Would it make sense then to […] rename the caskroom-versions repository to caskroom-unversioned?

No, because there are also unversioned casks in the main repo (the ones where the developer doesn’t provided a versioned download and updates the package in place).

That said, it does sound to me like the separate repository isn't actually needed, though, as it should be possible to treat the question of when url do is supposed to be used and when it's not supposed to be used as a matter of documentation, auditing, review, code comments, and pr templating just like anything else.

The point wasn’t url do, but this (emphasis added):

they are treated differently and are up to different standards; having them in a separate tap makes sense.

Different standards; different treatment; different tap.

[ilovezfs]

OK so can someone please suggest an acceptable name that doesn't involve changing the brew backend?

[ilovezfs]

e.g. maybe homebrew/homebrew-cask-versions or homebrew/homebrew-cask-alternates?

[claui]

@ilovezfs I second that. Been trying back and forth with my own private(-ish) and public taps; the homebrew-foo/homebrew-cask-foo naming scheme has worked best for me personally.

One of my pet goals is, don’t memorize stuff, and don’t design anything that requires others to memorize stuff.

[ilovezfs]

@claui yeah name-spacing all of the cask taps as homebrew/homebrew-cask(-*) would make sense to me since just having the one tap homebrew/homebrew-cask have the word "cask" in it would be pretty confusing.

[reitermarkus]

@caskroom/maintainers, as part of my Google Summer of Code project, I will take on the task of migrating all Cask Taps into the Homebrew organisation.

Any objections to the homebrew/homebrew-cask naming scheme?

• homebrew/cask
• homebrew/cask-drivers
• homebrew/cask-eid
• homebrew/cask-fonts
• homebrew/cask-versions

[fanquake]

@reitermarkus I get a 404 with your GSOC link

[reitermarkus]

Should be working now.

[commitay]

It errors if I try to access it when I'm already logged in to google, works when I log out.

and by merging some brew cask commands with their brew counterparts

Which commands?

[reitermarkus]

Which commands?

search and cleanup

[MikeMcQuaid]

Any objections to the homebrew/homebrew-cask naming scheme?

homebrew/cask homebrew/cask-drivers homebrew/cask-eid homebrew/cask-fonts homebrew/cask-versions

Yes, sorry! I'd rather we didn't end up with a duplicate prefix for a Homebrew tap. The only tap with a current naming issue is homebrew-versions and I think it could be homebrew-cask-versions or similar. Ideally we'd also migrate some of the versions into homebrew-cask, too; for example many people end up tapping homebrew-cask-versions purely for java8 (which would ideally be java@8, too).

[commitay]

it could be homebrew-cask-versions

I think this is what it would be as homebrew/cask-versions would still require the homebrew- prefix?

Ideally we'd also migrate some of the versions into homebrew-cask, too; for example many people end up tapping homebrew-cask-versions purely for java8

I'd be okay with making an exception for java8 but I'm still prefer to keep all the other "versions" in their own repo.

[MikeMcQuaid]

I think this is what it would be as homebrew/cask-versions would still require the homebrew- prefix?

It wasn't clear to me whether homebrew/cask-versions meant https://github.com/Homebrew/homebrew-cask-versions or https://github.com/Homebrew/cask-versions. If it's the prior: 👍 to all the above (and apologies @reitermarkus)!

I'd be okay with making an exception for java8 but I'm still prefer to keep all the other "versions" in their own repo.

👍 that would be good.

[reitermarkus]

Yes, I meant the full versions, but used the short versions since they are usually what's used when using brew tap.

So that is homebrew/homebrew-cask(-*).

[MikeMcQuaid]

@reitermarkus Gotcha 👍 from me all around, then. I was confused as there had been previous discussion about adding a new prefix.

[reitermarkus]

Before moving over the taps, we need to invite the @caskroom/maintainers who are not yet Homebrew maintainers, so I would like to ask everyone to read Homebrew's New Maintainer Checklist.

I the vein of

If you're no longer able to perform all of these tasks, please continue to contribute to Homebrew, but we will ask you to step down as a maintainer.

I think it's best to treat this as an opt-in, so please let us know if you feel you are able to continue to be a maintainer or not.

Thanks! 😉

[MikeMcQuaid]

Before moving over the taps, we need to invite the @caskroom/maintainers who are not yet Homebrew maintainers, so I would like to ask everyone to read Homebrew's New Maintainer Checklist.

@reitermarkus Actually we can (and I think should) create a new separate team that's just for access to all of the Cask stuff.

I think it's best to treat this as an opt-in, so please let us know if you feel you are able to continue to be a maintainer or not.

I agree with this regardless 👍

[reitermarkus]

Actually we can (and I think should) create a new separate team that's just for access to all of the Cask stuff.

I already moved the maintainers/brew/cask team to maintainers/cask.

[commitay]

I already moved the maintainers/brew/cask team to maintainers/cask.

The cask sub-team within maintainers/brew was useful for reviews, is it possible to have both?

[claui]

@reitermarkus Happy to see the projects moving closer together! Having been a Cask maintainer since 2014 (with the odd hiatus), I’ve decided to commit to what the New Maintainer Checklist says.

Looking forward to – finally – become part of the org 😊

[claui]

@reitermarkus Thanks for adding me.

I noticed I’ve been added to the cask team. I’ll do Cask maintenance if the project really needs it but I’m neither very skilled nor efficient at it. Working on the Cask core is what I’ve been good at though. That’s what I used to do (until the 2016 reorg came along) and what I’d like to pick up doing.

What would be a good path to get me moved back to the (Cask) core team?

[reitermarkus]

What would be a good path to get me moved back to the (Cask) core team?

I will add you to the Homebrew/brew team. Also, please let me know your email so I can invite you to the Homebrew Slack.

[reitermarkus]

I will begin moving over the taps later today.

[vitorgalvao]

Questions:

1. After moving the taps, will the old ones be immediately dead (breaking every brew cask install caskroom/cask/… command), or will Github redirect automatically?
2. If Github redirects automatically, how long will the redirect last?
3. If Github does not redirect, doesn’t that mean we’ll need a simultaneous HB release that includes the new URLs?

[reitermarkus]

1. Github will redirect it. You can test this: https://github.com/caskroom/homebrew-tap-migration-test
2. I don't think there is a time limit.

[MikeMcQuaid]

There's no time limit; it'll be redirected as long as there's not a new repository created with the same name.

[vitorgalvao]

Just noticed I only have read permissions on the repos.

On another note, just did a quick update to cask-repair (I was hoping the automatic redirect would make it not immediately necessary, but it seems it did indeed break). I’m really tired so I’ll likely go to sleep soon. If there are users complaining about cask-repair not working, please tell them to update (already bumped the formula — it’s at 0.37.0) and that if the issue persists to submit bug reports to https://github.com/vitorgalvao/tiny-scripts instead (the script already says that, but we still get people opening issues in this repo).

Thank you, talk in a few hours!

[commitay]

I've opened https://github.com/Homebrew/homebrew-cask/pull/47609 to discuss moving java8

[reitermarkus]

Just noticed I only have read permissions on the repos.

@vitorgalvao, the @Homebrew/cask team has write access to all Cask repos, so not sure why it's not working for you.

@commitay, I also explicitly added read access for Hombrew/brew, so @Homebrew/cask can be used for reviews.

[MikeMcQuaid]

@vitorgalvao, the @Homebrew/cask team has write access to all Cask repos, so not sure why it's not working for you.

I added them yesterday, they were previously just Read.

[commitay]

I also explicitly added read access for Hombrew/brew, so @Homebrew/cask can be used for reviews.

Thanks!

[joshka]

Congrats on the move :) A long time coming. May I suggest that it would be cool to see a blog post on brew.sh about this to close the loop and cover out any of the things that are changing (e.g. analytics #47720, java8 #47609, etc.)

[MikeMcQuaid]

@joshka Thanks! We'll note it as part of the next major release.