Is dsource .org completely deserted?

[Nick Sabalausky]

"Joseph Rushton Wakeling" <joseph.wakeling at webdrake.net> wrote in message 
news:mailman.886.1337255711.24740.digitalmars-d at 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.