"Joseph Rushton Wakeling" <joseph.wakel...@webdrake.net> wrote in message news:mailman.886.1337255711.24740.digitalmar...@puremagic.com... > On 17/05/12 01:45, Nick Sabalausky wrote: >> My main point is that those features (fork/pull request/issue tracking, >> etc) >> should be decoupled from hosting so that, for example, self-hosted repos >> would *not* provide inferior service, in fact they woudn't have to >> provide >> some stupid bundled interface at all: As a *user* (NOT as a project >> maintainer), you would just use *your own* choice of github, bitbucket, >> Tortoise*, or whatever the fuck YOU wanted to use, to access whatever the >> fuck repo you wanted to access, wherever the hell said repo happens to >> live. >> The whole point is that interface and hosting have no business being >> coupled >> as they are now. Tying repo and interface together makes absolutely no >> sense >> whatsoever. > > I do agree with you. However ... to really get that working our only > choice is to take time and effort to contribute to one of the open source > code hosting solutions. I'm familiar with only two decent ones -- > Launchpad (which is tied to bzr) and Gitorious (which seems to be not very > well maintained these days, though I haven't looked too recently, and > which IIRC doesn't include issue tracking etc.). > > It would be great if we could have code-hosting equivalents of WordPress, > Drupal, Joomla! etc., but for now there's nothing that really cuts the > mustard compared to the dedicated services out there. >
That's not quite what I mean (actually, AIUI, bitbucket's software can already be installed on your own server and used like WordPress. It just won't know anything about any projects hosted on "http://bitbucket.org"; or anywhere else). What I'm suggesting is no different from, say, image files: 1. A repo should just be a repo. It's just data. No special interface attached other than just git or hg or whatever. It's *just* a repo. This is like a "png" file. 2. The protocols (ie. either git/hg/etc or better yet a standard extension that handles both git and hg) would then incorporate the things that github/bitbucket have proven to be commonly useful and franky *expected*, like fork-tracking, pull requests, issue tracking, etc. I'd imagine this would likely involve special extentions to the git/hg/etc repo format. But no matter how this is actually implemented, this would be like "libpng" (although it would likely have a standard cmd line and web-based interfaces, too - which wouldn't make sence for libpng, but it would be essential here). 3. Then, there would be optional *frontends* to #2, in either real-program form (like Tortoise*), or in shitty-web-app form (GitHub mark 2, BitBucket mark 2, etc). These would *not* be like WordPress/etc, because WordPress/etc are packaged together with data. Instead, these would be like Photoshop, GIMP, or whatever crappy web-app equivalent people might like. Have you ever heard of, or even read, "Hugi Magazine"? ( http://www.hugi.scene.org/main.php?page=hugi ). It has interesting content, but the format is absolutely moronic: Instead of coming in PDF or HTML or even DOC or dead-tree, it comes in *EXE* form. That's right. So you can't use your choice of viewer, and you can't even read it on another device without them actually *porting* the fucking issue. GitHub/BitBucket/etc (along with 90% of "Web 2.0" and "cloud"), are very, very much like Hugi. And yet somehow, people seem to think it's a fantastic *advancement*. Bleh. > Bear in mind, though, that even if you _did_ have the stuff available for > self-hosting, in many cases it would still make sense to host with a > dedicated service. Totally agree. The point here isn't to stop or obsolete hosting services, it's just to properly decouple "data" from "software". Some of the consequences of that: A. Coder Joe finds project FooBar. He browses the source, browses through the *forks* (*even* forks hosted *elsewhere*), makes his own fork (no matter where or how he chooses to host it), and creates/browses pull-requests and issue-tickets through the interface of *his own* choosing, not some interface chosen by FooBar's maintainer. B. FooBar's maintainer doesn't even have to provide *any* special "WordPress equivalent" interface or anything, no matter *how* or where he chooses to host FooBar's official repo. He just exposes the repo (with the standard extensions to allow all this stuff) either on his own server, or on any hosting site, and that's it: He's done, and his project automatically has all the GitHub/BitBucket-like benefits everyone has come to expect, and all regardless of how or where he chooses to host FooBar. And his users can use whatever interface *they* prefer. *Everyone* wins. *Everyone* gets their *own* way. C. Self-hosting becomes a perfectly reasonable option, unlike now. D. External hosting, like with GitHub/BitBucket, *continues* to be a perfectly reasonable option.
