The “trough” project

[vitorgalvao]

I’m pinging collaborators, but any user/contributor is welcome to chime in, since this policy consideration affects all users.
@phinze @passcod @nanoxd @fanquake @leoj3n @rolandwalker @kevinSuttle

We have a policy of accepting only the official (or other trusted) sources for the download url of apps (as we should). This has lead to the refusal of certain casks. However, there’s a new project, maintained by @alebcay (for those of you who haven’t encountered him before, he has been contributing a torrent (as in “flood”, not the technology) of well made casks, recently), that aims to provide “app binaries of open-source projects to the homebrew-cask project”.

I have no reason to doubt his good intentions (quite the contrary), but I also do not think this decision should be made by a single person (well, maybe @phinze, since it’s his project, but he’s also an excelent maintainer and I doubt he’d make this decision in a vaccuum). Users come first, and if an app is not being provided officially, it’s our responsibility to assure the source is trustworthy, or at least make it painfully clear when we just don’t know.

All that said, I believe this project could prove itself to be a valuable addition, and the issue here is to decide to accept links from it or not. I see two main options for this

1. We accept links from trough like we do from any other source, and we trust @alebcay (and any other contributors he trusts) to care for quality control of submissions.
2. We decide only official links are to be supported by the main homebrew-cask tap, and for trough apps to be installed via homebrew-cask, they’ll have to be added from a different tap.

Following option 2, we could then consider, with @alebcay’s consent, to make that tap an official part of the project (albeit decoupled from the main part, much like versions is) or not.

We have users that greatly care about security (one of the reasons having all the casks with a checksum is a consideration), with good reason. It’s one thing to provide an official link, and another to provide links to apps not compiled by the official source. The latter might decrease trust from users, since we’re effectively asking them to trust another source we trust (that’s an extra step).

For the above reason, I’m more inclined to the second option, even making it official. This way we have a tap that users can easily access and understand the repercussions of doing so, and by making it official we’d likely increase its popularity and contributions. Sure, it’s one extra step, but the user’s trust is paramount.

[rolandwalker]

+1 for a new official Tap in caskroom, and +1 for giving @alebcay all the support and assistance he may need.

There are many apps like this that users want to install, but they currently fall "between the cracks" between this project and Homebrew.

[alebcay]

+1 for the tap idea, I would personally prefer that over my previous approach.

[phinze]

Thanks for the thorough writeup @vitorgalvao, and MAJOR thanks @alebcay for all your work on both homebrew-cask and trough!

I am also partial to the "official tap" idea. I think it might even be worth considering adding our official taps to the default search results. Homebrew recently started doing this with their -versions tap, and I think it might be worth considering for -fonts and -through taps. That's a discussion for a separate issue though. 😀

What do you think, @alebcay, does https://github.com/caskroom/homebrew-trough / brew tap caskroom/trough sound good to you?

[alebcay]

@phinze I'm all for it! Perhaps we should have it renamed to something more informative, such as caskroom/diy or something.

Also, I'd like to make sure I don't misunderstand what's being suggested here: under this plan, we're moving the Caskfiles for such "unofficial" apps into the new repo, right? Not the actual download links (e.g. DMGs, etc.).

[rolandwalker]

@alebcay yes, the proposed new repo would be a Homebrew Tap, all of which gets synced to a user's machine when they brew update. So the builds should not be checked in. But you can attach binaries within GitHub, right? That's what I assumed you were going to do.

diy seems confusing to the user. S/he might think it means the user needs to do something extra. caskroom/builds?? But maybe I'm bikeshedding.

[alebcay]

I'm not too concerned about the name, it's just that trough offers no informational content whatsoever. So, you're saying that the disk image for some app, let's say, BugHub, would be hosted at essentially https://github.com/caskroom/homebrew-builds/raw/master/osx/BugHub.dmg?

[rolandwalker]

Pathnames: Homebrew enforces a convention that the repo name for a Tap must start with homebrew-. But it also permits the user to leave out that prefix. So when we write brew tap caskroom/builds, that refers to a repo with the full name homebrew-builds located at https://github.com/caskroom/homebrew-builds .

Binaries in the repo: Unless there's some trick I'm unaware of, the DMGs shouldn't be checked into the repo which is also a Tap, because that means they all get downloaded to every user. I was assuming you would use the feature of attaching binaries to a release within GitHub (example: https://github.com/rolandwalker/limechat/releases) but that was just an assumption, I don't mean to advocate that this is the only way to serve your files.

You will also run up against GitHub's size limits if you check in a large number of DMGs into a repo: https://help.github.com/articles/what-is-my-disk-quota .

[alebcay]

Hmm, I've actually gone over the 100MB per file limit before with some Linux ISOs, but I guess I shouldn't push the rules until they break. And yes, I just remembered the naming rule about Homebrew taps (I have changed my previous comment about the URL). I never thought of distributing apps through the releases system, although I guess it could work.

Also, for the record, the current repo name is trough, not through or though, but I can understand the confusion.

[rolandwalker]

Maybe you should join us on IRC tomorrow (today is a holiday for many in the USA) to hash out these logistical details.

[alebcay]

I'm still in school (hehe), and we have school these couple of days due to the past snowy week on the east coast, so I'm afraid I can't. However, I have the feeling that I'm not the most qualified to make these types of technical details; the furthest I've made it up the software management chain levels out at "field worker".

I am on IRC right now, and I leave it on during the day.

[alebcay]

Just a note, I've renamed the organization trough (http://github.com/trough) to alehouse(http://github.com/alehouse) to avoid confusion with previous typos through, though, etc., and also to assist non-English speakers. Also, forked each project individually so that updates can be pulled from upstream easily and rebuilt, and also to avoid hitting storage quotas on individual repositories.