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.

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.

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

"Nick Sabalausky" <SeeWebsiteToContactMe@semitwist.com> wrote in message news:jp3ocp$2e1c$1@digitalmars.com...
>
> 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).
>

Sorry, what I meant there was "it would likely have standard cmd line and web ***API*** interfaces". Ie, not actual web pages, but a web service protocol, like a REST API, or SOAP (minus the XML, preferably) or whatever the hell the popular equivalent is these days. ;)

"Nick Sabalausky" <SeeWebsiteToContactMe@semitwist.com> wrote in message news:jp3oq2$2esa$1@digitalmars.com...
> "Nick Sabalausky" <SeeWebsiteToContactMe@semitwist.com> wrote in message news:jp3ocp$2e1c$1@digitalmars.com...
>>
>> 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).
>>
>
> Sorry, what I meant there was "it would likely have standard cmd line and web ***API*** interfaces". Ie, not actual web pages, but a web service protocol, like a REST API, or SOAP (minus the XML, preferably) or whatever the hell the popular equivalent is these days. ;)
>

Or hell, doesn't even have to be web, could be SCGI or a new thing or whatever, just some standardized network protocol.

On Thu, May 17, 2012 at 04:51:04PM -0400, Nick Sabalausky wrote: [...]
> 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.
[...]

Is it really _that_ bad? GitHub does support directly running git pull/push, clone, etc. just by specifying the URL.  If you want to send somebody a pull request, you could just put your repo on any git hosting service (or run your own), and email the relevant people the URL to your repo. Then they can just run git pull $url and that's that.

Though you do have a point that a standard protocol for pull requests, issue tracking, etc., would be nice. If git was extended to have, say, discussion tracking for pull requests, then people can actually discuss your requests in a hosting-independent way, and you can, e.g., run 'git pull discuss --client=mutt' to read discussions via Mutt or whatever your favorite non-dumb mail/news reader is. But this is more a limitation of the current git protocol than the fault of any of the present hosting systems. You could, y'know, send pull requests to the upstream git source to rectify this situation... ;-)


T

-- 
Creativity is not an excuse for sloppiness.

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.902.1337292243.24740.digitalmars-d@puremagic.com...
> On Thu, May 17, 2012 at 04:51:04PM -0400, Nick Sabalausky wrote: [...]
>> 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.
> [...]
>
> Is it really _that_ bad? GitHub does support directly running git pull/push, clone, etc. just by specifying the URL.  If you want to send somebody a pull request, you could just put your repo on any git hosting service (or run your own), and email the relevant people the URL to your repo. Then they can just run git pull $url and that's that.

Well no, it's not *that* bad (that's why I said "very much like" rather then "the same as"), but it's along the same general lines - just not quite as far.

>
> Though you do have a point that a standard protocol for pull requests, issue tracking, etc., would be nice. If git was extended to have, say, discussion tracking for pull requests, then people can actually discuss your requests in a hosting-independent way, and you can, e.g., run 'git pull discuss --client=mutt' to read discussions via Mutt or whatever your favorite non-dumb mail/news reader is. But this is more a limitation of the current git protocol than the fault of any of the present hosting systems.

Right, exactly.

> You could, y'know, send pull requests to the
> upstream git source to rectify this situation... ;-)
>

That means I'd have to actually find the time to write them ;)  (and deal with C/Pyton/etc... Yuck!)

Thing is though, these features have *already* been created, *multiple* times, by multiple groups of people. And yet, every single time, it was done basically the wrong way. That bugs me. ;)

But you're right, the solution is for someone to actually *make* the "right" solution. My main point for now though, was just to at least get across the idea of what the "right" way even *is* and why it's better. It's only a small first step, but a necessary first step.

> -- 
> Creativity is not an excuse for sloppiness.

Heh :)

On 5/18/12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> Is it really that bad?

Speaking of Github, it's really annoying how many projects get listed here even though they have nothing to do with D: https://github.com/languages/D/created

I don't understand how Github manages to pick up so many java/cpp codebases and mark them as D codebases.

"Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message news:mailman.904.1337305802.24740.digitalmars-d@puremagic.com...
> On 5/18/12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
>> Is it really that bad?
>
> Speaking of Github, it's really annoying how many projects get listed here even though they have nothing to do with D: https://github.com/languages/D/created
>
> I don't understand how Github manages to pick up so many java/cpp codebases and mark them as D codebases.

I wonder if it's trying to detect D files with '*d' instead of '*.d'  Or, maybe an accidental regex for '.d$' instead of '\.d$'  The [few] projects in there that I looked at all had either a "README.md" or at least some filename that ended with a "d".

Am Thu, 17 May 2012 22:10:23 -0400
schrieb "Nick Sabalausky" <SeeWebsiteToContactMe@semitwist.com>:

> "Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message news:mailman.904.1337305802.24740.digitalmars-d@puremagic.com...
> > On 5/18/12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> >> Is it really that bad?
> >
> > Speaking of Github, it's really annoying how many projects get listed here even though they have nothing to do with D: https://github.com/languages/D/created
> >
> > I don't understand how Github manages to pick up so many java/cpp codebases and mark them as D codebases.
> 
> I wonder if it's trying to detect D files with '*d' instead of '*.d'  Or, maybe an accidental regex for '.d$' instead of '\.d$'  The [few] projects in there that I looked at all had either a "README.md" or at least some filename that ended with a "d".

Now that's funny. I just looked at one such project and it had neither README.md, nor files ending in d. There were a few shell scripts which made up about half of the project and patches to Python 2.7. So no real programming language used. Yet GitHub shows:

D     83.8%
C     12.8%
Shell  2.7%
Other  0.6%

Assuming the .sh scripts get correctly recognized, there is something huge accounted for that doesn't actually exist in the repository. I'm sure there is already more than one bug report about this, as it is pretty obvious!

-- 
Marco