I agree. That way it will become more apparent what really needs to be
written for D. Currently there "appears" to be a lot of stuff written for
D, when there's not more, then just a few.
Also, I think there should be a strict division of D1 and D2 projects
(where projects, supporting both would appear in both categories).
For instance, there's the DDL library for custom dynamic libraries in D,
but it' D1 only, making it completely useless for the vast majority of D
programmers.


On Tue, May 15, 2012 at 2:11 PM, Dmitry Olshansky <dmitry.olsh@gmail.com>wrote:

> On 15.05.2012 14:04, Gor Gyolchanyan wrote:
>
>> Derelict 3 is under development and is on github, so Derelict is not
>> gonna be on dsource.org <http://dsource.org> for too long,
>> A plethora of dead projects on dsource.org <http://dsource.org> is a
>>
>> good way to scare away newcomers, i think.
>>
>>
> I think that a global purge can save it. Just archive/move away all of projects not updated for more then 1 year into some sort of Archive section. In case of misfire author can just contact admin and get his project reinstated.
>
>
> --
> Dmitry Olshansky
>



-- 
Bye,
Gor Gyolchanyan.

On Tuesday, 15 May 2012 at 02:36:25 UTC, Nick Sabalausky wrote:
> "Kapps" <opantm2+spam@gmail.com> wrote in message
> news:gvuqhcqczjqmdtpsagrj@forum.dlang.org...
>> It would be nice to make a replacement to dsource. There's a fair few problems with it. For one, people prefer hosting their source on Github or Bitbucket or such, it's silly to try and get people to use your own source control hosting instead of just pointing to one of those.
>
> I firmly believe that GitHub/BitBucket/etc-style features need to be
> standard *protocols*, not features bundled inseparably to project hosting.
> What the hell is this, 1980 all over again where data is routinely tied
> inseparably to the software it originated from?
>
> It makes *no* sense for GitHub/BitBucket to be designed so that:
>
> 1. Forking/Pull requests/etc are all isolated from other project hosting
> providers (It's *DISTRIBUTED* fucking version control, for christsakes!),
> and
>
> 2. Interfaces [very, very VERY sloooow and half-broken ones] are tied to the
> project hosting site/software.
>
> It's like that twitface shit all over again (ie, all that "walled-off
> sub-internets" bullshit), or those god-awful "web photo-viewer" programs,
> but with programmers - exactly the people who *should know better*. This is
> 2012, there's *no* excuse for software design blunders that were already
> going out of date 30 fucking years ago.
>
> Of course, such anachronisms will never be reverted so long as the "cell and
> internet generation" is still around...
>
>> Another would be to integrate package manager stuff when one is available. And, most importantly, to prioritize active projects and focus out dead projects automatically.
>>
>
> I agree, such things would be nice. There also needs to be proper use of
> HTTPS for logins/sessions, and automated creation of new projects.

There *is* such a protocol - it's called Git.
Sure it doesn't support pull requests but that's the base for
GitHub's business model - they make money by offering useful
extensions on top of their hosting plans. There is no blunder
here, it's all very deliberate for the purpose of making money.
There's no point on ranting about that.

Git is open source - anyone can contribute and implement these
missing features. Besides, no ones forcing you to use GitHub, you
can easily self-host directly with the bundled daemon or use
additional open-source software such as Gerrit that also provides
the same features as GitHub.

This is akin to ranting about commercials on the radio while
listening to music. Well, they do need to make money in order to
provide free (as in beer) music. If someone doesn't like it he's
free to arrange the music himself on an MP3 or a CD.

On 5/15/2012 7:04 PM, Gor Gyolchanyan wrote:
> Derelict 3 is under development and is on github, so Derelict is not
> gonna be on dsource.org <http://dsource.org> for too long,

It will be there as long as DSource exists. I have no plans to move it. My only real alternatives for the forum is to host it on my personal site or make a new one. Neither is very appealing to me at the moment.

"foobar" <foo@bar.com> wrote in message news:cuucmsymdqnsrurlkfpg@forum.dlang.org...
> On Tuesday, 15 May 2012 at 02:36:25 UTC, Nick Sabalausky wrote:
>> "Kapps" <opantm2+spam@gmail.com> wrote in message news:gvuqhcqczjqmdtpsagrj@forum.dlang.org...
>>> It would be nice to make a replacement to dsource. There's a fair few problems with it. For one, people prefer hosting their source on Github or Bitbucket or such, it's silly to try and get people to use your own source control hosting instead of just pointing to one of those.
>>
>> I firmly believe that GitHub/BitBucket/etc-style features need to be
>> standard *protocols*, not features bundled inseparably to project
>> hosting.
>> What the hell is this, 1980 all over again where data is routinely tied
>> inseparably to the software it originated from?
>>
>> It makes *no* sense for GitHub/BitBucket to be designed so that:
>>
>> 1. Forking/Pull requests/etc are all isolated from other project hosting providers (It's *DISTRIBUTED* fucking version control, for christsakes!), and
>>
>> 2. Interfaces [very, very VERY sloooow and half-broken ones] are tied to
>> the
>> project hosting site/software.
>>
>> It's like that twitface shit all over again (ie, all that "walled-off
>> sub-internets" bullshit), or those god-awful "web photo-viewer" programs,
>> but with programmers - exactly the people who *should know better*. This
>> is
>> 2012, there's *no* excuse for software design blunders that were already
>> going out of date 30 fucking years ago.
>>
>> Of course, such anachronisms will never be reverted so long as the "cell
>> and
>> internet generation" is still around...
>>
>
> There *is* such a protocol - it's called Git.

Right, I agree, but these days, Git (or Hg) is essentially only a half-VCS without such things. And Git and Hg don't have such things.

> Sure it doesn't support pull requests but that's the base for GitHub's business model - they make money by offering useful extensions on top of their hosting plans. There is no blunder here, it's all very deliberate for the purpose of making money. There's no point on ranting about that.
>

I'm well aware that it's deliberate, but it's still anti-competetive, asinine and anachronistic. And it's not as if the whole hosting thing isn't worth anything. That is, after all, what they *do*.

People have this bizarre idea that the pursuit of $$$ automatically excuses anything and everything. "WTF, that's terrible!" "No, it's ok: They're making $$$ off of it!" "Oh, ok then! If they're making $$$!"

This is why OSS software will always be better (on average) than commercial: No managers to fuck things up.

"Nick Sabalausky" <SeeWebsiteToContactMe@semitwist.com> wrote in message news:jottlr$stf$1@digitalmars.com...
> "foobar" <foo@bar.com> wrote in message news:cuucmsymdqnsrurlkfpg@forum.dlang.org...
>
>> Sure it doesn't support pull requests but that's the base for GitHub's business model - they make money by offering useful extensions on top of their hosting plans. There is no blunder here, it's all very deliberate for the purpose of making money. There's no point on ranting about that.
>>
>
> I'm well aware that it's deliberate, but it's still anti-competetive, asinine and anachronistic. And it's not as if the whole hosting thing isn't worth anything. That is, after all, what they *do*.
>

Wait, what the hell am I thinking? Even if is deliberate, and even if "$$$!!" did excuse everything, it *still* doesn't even make a shred of sense anyway: They *already* offer a free API which can be used for any of the different forms of interop I was suggesting. So they're *already* ok with all of what I suggested. Locking out interop is *not* part of their business model. They've just implemented that interop in a colossally dumb way, that's all.

On Tue, 15 May 2012 11:43:42 -0400, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> I'm well aware that it's deliberate, but it's still anti-competetive,
> asinine and anachronistic. And it's not as if the whole hosting thing isn't
> worth anything. That is, after all, what they *do*.

Wait, can't you just git clone the data into whatever "github-like" service you wish?  I mean, yeah, you cannot do pull requests to Phobos unless you have your code in github, but that could just be a simple intermediate step.

I recently switched all my private repositories from github to bitbucket (free unlimited private repositories vs. $12/mo for 10 private repositories), and bitbucket actually has a page to suck the code from github *directly*  I didn't even have to do the git-clone-locally-then-push-to-other-remote dance.  Probably the easiest service change of anything in my entire life!  It took all of 5 minutes.

So if you like bitbucket, use that, if you like github use that, if you like something else, use that.  But if you want to contribute to a project, you have to use whatever that project uses.  I think that's both very reasonable and very flexible.

-Steve

On May 16, 2012, at 9:38 PM, Steven Schveighoffer wrote:

> On Tue, 15 May 2012 11:43:42 -0400, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> 
>> I'm well aware that it's deliberate, but it's still anti-competetive, asinine and anachronistic. And it's not as if the whole hosting thing isn't worth anything. That is, after all, what they *do*.
> 
> Wait, can't you just git clone the data into whatever "github-like" service you wish?  I mean, yeah, you cannot do pull requests to Phobos unless you have your code in github, but that could just be a simple intermediate step.

This is not entirely correct. You can do pull requests. You just can't do them through the github interface, which aims to make them easier and smoother. A pull request is nothing more than a request to execute a common git command with a URL pointing to a git repository (which can be hosted anywhere). The github interface just wraps this command and directs it to the repository stored on the server rather than one on your computer (as well as adding things like tracker integration, etc).

From the git documentation:

Often, "please pull" messages on the mailing list just provide two pieces of information: a repo URL and a branch name; this is designed to be easily cut&pasted at the end of a git fetch command line:

    Linus, please pull from

	git://git..../proj.git master

    to get the following updates...

becomes:

    $ git pull git://git..../proj.git master

(See http://git-scm.com/docs/git-tag)

Projects that don't operate around sites like github rely on messages to a mailing list asking the integrator to pull from some branch of some repository. Although I'm sure the Linux kernel works like this, I haven't seen it, but I have seen the same process used effectively by Erlang - and they even use github for their repositories.

If Phobos is *requiring* pull requests to be done through the github interface, well, I think that's pretty silly and a good way to discourage some contributions, but it's not my project and perhaps they like the interface too much to work any other way.


Geoff

On 16/05/12 15:09, Geoffrey Biggs wrote:
> Projects that don't operate around sites like github rely on messages to a mailing list asking the integrator to pull from some branch of some repository. Although I'm sure the Linux kernel works like this, I haven't seen it, but I have seen the same process used effectively by Erlang - and they even use github for their repositories.

You can also generate patches and attach to email, so discussion/review of the patch can happen on the list.  IIRC the Bazaar project does this, and they even have some kind of automated vote-tracking system in place that lets authorized individuals assent, dissent or abstain from merging a patch into the trunk.

On 15/05/12 04:16, Nick Sabalausky wrote:
> I firmly believe that GitHub/BitBucket/etc-style features need to be
> standard *protocols*, not features bundled inseparably to project hosting.
> What the hell is this, 1980 all over again where data is routinely tied
> inseparably to the software it originated from?

Whatever your opinion of GitHub etc. (and I agree that it makes sense for there to be a well-defined set of interaction protocols), the key point is surely that dedicated code-hosting and collaboration platforms can provide a much better service than individual projects' self-hosted repositories.

Where dsource.org is concerned probably the best thing to do is make it a carefully-maintained directory of active projects, without hosting, issue tracking, etc. included (of course, existing repos should be kept in place to avoid data loss).  It's unlikely to be much pain for the projects, who can be given plenty of notice to migrate.

As it stands it makes D look quite dead and derelict, when that's not the case at all.

"Joseph Rushton Wakeling" <joseph.wakeling@webdrake.net> wrote in message news:mailman.840.1337179907.24740.digitalmars-d@puremagic.com...
> On 15/05/12 04:16, Nick Sabalausky wrote:
>> I firmly believe that GitHub/BitBucket/etc-style features need to be
>> standard *protocols*, not features bundled inseparably to project
>> hosting.
>> What the hell is this, 1980 all over again where data is routinely tied
>> inseparably to the software it originated from?
>
> Whatever your opinion of GitHub etc. (and I agree that it makes sense for there to be a well-defined set of interaction protocols), the key point is surely that dedicated code-hosting and collaboration platforms can provide a much better service than individual projects' self-hosted repositories.
>

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.

What we have now is *no* different from those god-awful, absolutely rediculous, image sharing "tools" like Kodak Photo Viewer or Adobe Lightroom's Flash exporter. (I *hate* when people try to send me pictures with those reprehensible things.) Or Flash-based videos: Why the hell is it so incredibly unacceptable for people to use THEIR OWN fucking choice of video player? In any case, github/bitbucket/etc are exactly the same thing, just with code instead of picutres or videos (and made by and for people who are smart enough that they *should* know better).

>
> As it stands it makes D look quite dead and derelict, when that's not the case at all.

Agreed. DSource could use some improvements WRT finding active/inactive projects.