May 13, 2012
On 5/13/2012 10:41 AM, Brad Roberts wrote:
> Also, for what it's worth, a project with
> multiple contributors are is much more likely to survive for the long haul than a one man project.

A number of great projects still "die on the vine". The problem is, it's not enough to create a great project. You've got to flog it. All successful businesses know this - they have huge marketing & promotion efforts.

Consider the ipad. Is it so great that Apple doesn't need to do any marketing or promotion? Maybe, but there's no way in hell Apple is going to take such a risk. I see Apple promotion for it everywhere.

Flogging it would be things like:

1. Writing articles about it.

2. Doing presentations on it.

3. Keeping an eye on the forums, newsgroups, reddit, etc., for opportunities to mention it.

4. Google has a feature where they'll email you links to any new hits on a search topic. It's a great way to find other articles on your products, or related ones.

5. Writing tutorials about it.

6. Having some decent web site for it.

For example, coming to the D Conference in September and doing a presentation/workshop on it!

Fortunately, the above doesn't cost money, but it does cost significant time. But look at it this way - if you aren't willing to flog it, then the time you invest in developing it is likely wasted, unless you're lucky enough that another champion emerges to do it for you.
May 14, 2012
On 5/13/2012 3:25 PM, Ary Manzana wrote:
> On 5/13/12 7:31 PM, Rainer Schuetze wrote:
>> With the workflow of bugzilla/svn it was just copy and pasting the diff
>> into the bug report. I understand it is easier on Walter's side, though.
>
> But where did you get the diff from? I'm sure you checked out the
> project and made the changes on it. If that's the case, then it's the
> same as forking and cloning.

With small patches to a single file (which is what most patches are), it was just the diff to the svn working base that you could copy and paste from a shell context menu command. You could even adjust the diff manually to filter out other unrelated changes. With pull requests you have to redo the patch on a clean branch of the full source tree. Maintaining larger patches did get messy, though.

>
> I *do* expect contributions to appear in Visual D. Since it's so easy to
> contribute in github, and it is standarized: people know how to do it:
> fork, work, make a pull request (as opposed to making a patch, sending
> it... mmm... is that the author's email? I hope it does work. And I hope
> it checks emails and mine doesn't go to the spam folder! Um, maybe I
> should post in the forums... but does he read them? Ah, maybe I will
> leave the patch for another day).

Well, the bug-tracking system is/was probably the right place. But I agree, the infrastructure provided by github is very impressive and might be more attractive to contributors.

May 14, 2012

On 5/11/2012 9:49 PM, Walter Bright wrote:
> On 5/1/2012 9:46 AM, Rainer Schuetze wrote:
>> The Visual D installer can be downloaded from its website at
>> http://www.dsource.org/projects/visuald
>
> Can you please move it to github?
>

I will give it a try...
May 24, 2012
On 13/05/12 21:28, Walter Bright wrote:
> On 5/13/2012 5:31 AM, Rainer Schuetze wrote:
>> With the workflow of bugzilla/svn it was just copy and pasting the diff
>> into the bug report. I understand it is easier on Walter's side, though.
>
> Yes, it is definitely easier on my side.
>
> But consider that the number of contributions to dmd has increased by at
> least a factor of 10 since we moved to github means that, in general,
> contributors find it easier, too.

As I've said before -- that is true for DMD but not for Phobos.
Rate of contributions to Phobos is basically the same as when it was in svn.
Would be good to know why.
May 24, 2012
On Thu, 24 May 2012 09:30:01 -0400, Don Clugston <dac@nospam.com> wrote:

> On 13/05/12 21:28, Walter Bright wrote:
>> On 5/13/2012 5:31 AM, Rainer Schuetze wrote:
>>> With the workflow of bugzilla/svn it was just copy and pasting the diff
>>> into the bug report. I understand it is easier on Walter's side, though.
>>
>> Yes, it is definitely easier on my side.
>>
>> But consider that the number of contributions to dmd has increased by at
>> least a factor of 10 since we moved to github means that, in general,
>> contributors find it easier, too.
>
> As I've said before -- that is true for DMD but not for Phobos.
> Rate of contributions to Phobos is basically the same as when it was in svn.
> Would be good to know why.

Phobos is perfect.

:)

-Steve
May 24, 2012
On 5/24/12 20:30 , Don Clugston wrote:
> On 13/05/12 21:28, Walter Bright wrote:
>> On 5/13/2012 5:31 AM, Rainer Schuetze wrote:
>>> With the workflow of bugzilla/svn it was just copy and pasting the diff
>>> into the bug report. I understand it is easier on Walter's side, though.
>>
>> Yes, it is definitely easier on my side.
>>
>> But consider that the number of contributions to dmd has increased by at
>> least a factor of 10 since we moved to github means that, in general,
>> contributors find it easier, too.
>
> As I've said before -- that is true for DMD but not for Phobos.
> Rate of contributions to Phobos is basically the same as when it was in
> svn.
> Would be good to know why.

Maybe they are afraid to contribute.
May 24, 2012
On Thursday, 24 May 2012 at 13:30:03 UTC, Don Clugston wrote:
> Would be good to know why.

Probably (warning: unverified hypothesis ahead) because Phobos has much less »clear-cut« bugs – often, it's missing/restricted/clumsy functionality instead of obvious bugs. Also, Bugzilla has something like 4x the number of bugs for DMD compared to Phobos.

David
May 24, 2012
On 05/24/12 15:52, Steven Schveighoffer wrote:
> On Thu, 24 May 2012 09:30:01 -0400, Don Clugston <dac@nospam.com> wrote:
> 
>> On 13/05/12 21:28, Walter Bright wrote:
>>> On 5/13/2012 5:31 AM, Rainer Schuetze wrote:
>>>> With the workflow of bugzilla/svn it was just copy and pasting the diff into the bug report. I understand it is easier on Walter's side, though.
>>>
>>> Yes, it is definitely easier on my side.
>>>
>>> But consider that the number of contributions to dmd has increased by at least a factor of 10 since we moved to github means that, in general, contributors find it easier, too.
>>
>> As I've said before -- that is true for DMD but not for Phobos.
>> Rate of contributions to Phobos is basically the same as when it was in svn.
>> Would be good to know why.
> 
> Phobos is perfect.
> 
> :)

It's simple - if something doesn't work right in phobos, it gets redone
properly in user code, and then that phobos part is not needed anymore,
and it's almost never referred to anymore.
Compare with compiler problems - the user usually cannot work around bugs
or deficiencies, and even when it is possible - it usually carries some
kind of cost. So most compiler issues get reported and even sometimes
fixed, but this happens much less with the library; there it's easier to
just fix/rewrite the broken thing and be done with it.

The fact that D's std lib is so tiny, and practically every part of it has
several serious design problems (never mind implementation bugs) means it
gets used for learning and toy/example "programs". Once you start "real"
coding, the std lib might get a chance for some simple noncritical low-pri
tasks, such as debugging logs (and note that even that will often backfire),
but will rarely, if ever, be used for anything else. When you know you can
code a working solution in a few minutes, why risk spending time checking
if it exists in phobos, then learning how to use it from usually not very
helpful docs, fully realizing that most likely the library implementation
will be unusable, either because of a design flaw, bugs or a prohibitively
expensive implementation?
So paradoxically the low quality and tiny scope of phobos means that it
gets less contributions.

There are also other issues, like process, that hinder contributions, but those aren't specific to phobos. And the mythical backward compatibility, which - for a niche language with not a single mainstream compiler, not one alternative compiler (backends don't count), no specification and (statistically) no users, that constantly evolves, requiring adjusting code for almost every compiler and library release - is not nearly as important as it is made out to be.

IOW it's a chicken-and-egg problem - phobos needs to improve in order to receive a larger amount of improvements. Which is why things like a sane (and open, but that should go w/o saying) development process would make the most difference. But, realistically, even if all such issues would be fixed today, it would still take at least several years before a solid std library would start taking form. [1]

artur

[1] And what if GDC is merged into GCC during that time? It's not an unlikely scenario and one everyone should hope for. But, in practice, this will mean that DMD is no longer the reference compiler and the std library and runtime are effectively forked. I'd much prefer that as much as possible of the necessary language and stdlib changes to be done while Walter is still in some kind of control. And there are a lot changes left to be done.
June 06, 2012

On 5/14/2012 8:40 AM, Rainer Schuetze wrote:
>
>
> On 5/11/2012 9:49 PM, Walter Bright wrote:
>> On 5/1/2012 9:46 AM, Rainer Schuetze wrote:
>>> The Visual D installer can be downloaded from its website at
>>> http://www.dsource.org/projects/visuald
>>
>> Can you please move it to github?
>>
>
> I will give it a try...

After a number of WTF moments, it's finally available:

https://github.com/rainers/visuald

Let them pull requests keep comin'! (But please be patient, I will have to learn the procedures).

Rainer

June 27, 2012
On Wednesday, 6 June 2012 at 05:52:00 UTC, Rainer Schuetze wrote:
> After a number of WTF moments, it's finally available:
>
> https://github.com/rainers/visuald
>
> Let them pull requests keep comin'! (But please be patient, I will have to learn the procedures).
>
> Rainer

You might be interested in https://github.com/blog/1178-collaborating-on-github-with-subversion if you also plan to preserve subversion for some time.