Walter Bright wrote:
> Derek Parnell wrote:
>> On Mon, 16 Oct 2006 11:03:14 -0700, Walter Bright wrote:
>>
>>> I'm happy to merge things in, but am reluctant to do so without reviewing the diffs line by line.
>>
>> Actually, when I wrote "take Phobos", I really meant "take Phobos". You
>> would no longer have *the* sole controlling vote on what goes in or goes
>> out of phobos, nor would you have sole control over when new libraries were
>> released for general consumptuion. They would in fact be released
>> asynchonously from DMD. There would be 'beta' versions around for trying
>> our stuff and official releases for people who just needed a standard
>> library. Are you willing to give up control of Phobos?
> 
> Maybe after 1.0. I'm pretty reluctant to do so earlier. That said, it still doesn't impede anyone else from working on Phobos. An increasing number of my own contributions to it I've been making not just open source, but public domain.

I've noticed this, and it's very much appreciated.


Sean

Derek Parnell wrote:
> Walter Bright wrote:
>> Derek Parnell wrote:
>>> Walter Bright wrote:
>>>
>>>>I'm happy to merge things in, but am reluctant to do so without reviewing the diffs line by line.
>>>
>>>Actually, when I wrote "take Phobos", I really meant "take Phobos". You
>>>would no longer have *the* sole controlling vote on what goes in or goes
>>>out of phobos, nor would you have sole control over when new libraries were
>>>released for general consumptuion.
>>
>>Maybe after 1.0. I'm pretty reluctant to do so earlier. 
> 
> That's what I thought. I didn't really think that you meant what you said
> earlier ...
>
>>> Are you saying that, for example, you would have no problems with
>>> Phobos being taken from DigitalMars and moved to DSource so that
>>> everyone who needed to could get to submit changes to the library
>>> that would actually be applied.
>>
>> The license for the Phobos source code certainly allows that, and
>> that's part of the point of having the license be that way. So no,
>> I have no problem with that.
> 
>>That said, it still doesn't impede anyone else from working on Phobos.
> 
> What impedes me is you. The few times I have submitted a Phobos change to
> you, you have dismissed them as not worthy of the effort.

It's not like anyone has a *right* to get his code accepted.

One might submit reams of code, or one might be a Distinguished Member of the community, but every line of the code still has to earn its merits by itself!

The reasons of rejection may not be obvious to the submitter, but we have no reason to suspect Walter's motivation or impartiality! Or judgment.

And certainly one should not get personal about it.

---

As should be clear by now, it's free for anyone to set up Another Phobos right now. We might even have several different on separate servers. If any of these then turn up with worthy code, it could be copied to the others (or to the Official Phobos, if Walter so chooses).

And even before 1.0, if then somebody fancies one of the Independent Phoboses better than the original, then it's free to use that instead. (Then of course one would assume all responsibility for incompatibilities with 3rd party libraries or other code that may arise from the chosen Phobos possibly being "too fancy". But that's life.)

Walter Bright wrote:
> Georg Wrede wrote:
> 
>> -- Especially when the D community (as a whole, inlcuding DM) makes it exceptionally hard for the newcomer to ever get a grasp of what is available and what is outdated and where to start looking in the first place.
> 
> If you (or anyone else) would like to come up with a "getting started" text, including links for the best libraries, tools, etc., I'd be more than happy to host it on the Digital Mars D site.

It's not that simple. To really alleviate the "batteries not included problem", the list should be short and sweet.

This inevitably means recommending one GUI lib, one this and one that, and then showing from where, and how to get it up and running in no time. The whole point of the text being Simplicity.

But then every competing GUI and other lib would come crying about why they are not chosen or included. Even worse, if such a text were on the DM site itself, this would obviously give some semi-official status to the chosen, and the rivals would feel bad.

===========

There is a solution, but I don't know what folks think about it.

Suppose we let people create competing distros of D?

"Download Georg's distro, it's cool, or get Derek's distro, it's useful. Or get the plain DM distro and build your own system around it."

That's essentially how Linux does it.

Batteries included.

On Tue, 17 Oct 2006 09:33:10 +0300, Georg Wrede wrote:

> It's not like anyone has a *right* to get his code accepted.
>
> One might submit reams of code, or one might be a Distinguished Member of the community, but every line of the code still has to earn its merits by itself!

Do I really come across as that needy or foolish?

Don't bother replying. You have convinced me to have a long break from D participation. See you guys sometime after v1.0 is announced. It's time to dance to a different tune for awhile.

(BTW, I'll still support Bud while that's wanted though.)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
17/10/2006 4:42:06 PM

Walter Bright wrote:
> 
> I've thought about cash prizes and contests. I just had the nagging feeling that the result would be a circus rather than serious development.

What about bounties? We come up with a list of libraries we need/want and assign a $$ value to each item. They don't have to be big numbers. Anyone is free to submit an implementation of any item for your approval. If you accept the submission, you pay out the submitter and strike the item off of the list.

If you aren't comfortable handing out cash, perhaps you can reward them with a DMDScript license, a free Digital Mars CD, or whatever you feel comfortable with. At any rate, a bounty system focuses the concept more on seriousness and less on clowning around.

Derek Parnell wrote:
> What impedes me is you. The few times I have submitted a Phobos change to
> you, you have dismissed them as not worthy of the effort. Those responses
> just pissed me off and I can't be bothered trying too hard to work under
> that regimen anymore. I'm just now waiting for Phobos to be freed up so my
> workings can be judged against a wider body of opinion.

I think you've contributed a lot more to D, and have been appreciated more, than you realize. You've been listed on the D acknowledgements page for a very long time.

[depressing subject line -- let's change it]

Mike Parker wrote:
> Walter Bright wrote:
>>
>> I've thought about cash prizes and contests. I just had the nagging feeling that the result would be a circus rather than serious development.
> 
> What about bounties? 

Ooh.  I like that.  wxWidgets has a bounties page.
http://www.wxwidgets.org/wiki/index.php/WxWidgets_Bounties

I don't know how successful it is.  It looks active though.  Personally I'm more likely to put up a $100 for a bounty than I am to contribute $100 to a project in hopes they will make progress in the direction I want.

--bb

Georg Wrede wrote:
> Walter Bright wrote:
>> Georg Wrede wrote:
>>
> It's not that simple. To really alleviate the "batteries not included problem", the list should be short and sweet.
> 
> This inevitably means recommending one GUI lib, one this and one that, and then showing from where, and how to get it up and running in no time. The whole point of the text being Simplicity.
> 
> But then every competing GUI and other lib would come crying about why they are not chosen or included. Even worse, if such a text were on the DM site itself, this would obviously give some semi-official status to the chosen, and the rivals would feel bad.

Is there really so much D code that they couldn't just all be in there?  I'd love to have them all in one place so I could take em all for a spin and see what works for me.  How big would it be?  Python's up to a 10MB download now, but I'm certainly not complaining about it.  It could be 50MB for all I care.

The other option is to have something net-connected like the python easy_install stuff or the cygwin installer, or I suppose things like fink (though I've never used it), and apt-get.   Of those I think the Cygwin model makes most sense.  You get a front-end configurator to run that lets you pick which modules you want in addition to the core.  Of course that's a lot more work / infrastructure to set up.

--bb

Unknown W. Brackets wrote:
> If it can't be put in sourceforge, surely it could be put into a versioning repository (svn, cvs, etc.) of some sort.
> 
> Since it seems like digitalmars.com has a fairly reasonable hosting arrangement, this might even be possible using the current server and hosting company.
> 
> I think this has come up before, and Walter wasn't really interested in that.  I've really found version control systems as being a huge way to improve software quality and developer cooperation, though (even if only Walter had write access.)
> 
> -[Unknown]

I'd prefer sourceforge, where it will be seen by more people.

dsource is nice and has certainly done a lot for D, but it makes us look like some sort of cult.

L.

On Tue, 17 Oct 2006 00:16:53 +0300, Georg Wrede <georg.wrede@nospam.org> wrote:
> Walter Bright wrote:
>> Knud Sørensen wrote:
>>> clayasaurus wrote:
>>>> Knud Sørensen wrote:
>>>>
>>>>> What about the library contest I suggested long ago ?? Is that a useful idea?
>>>>
>>>> How about a "Top 10 D libraries" page on digitalmars D where the D community votes for the top 10 libraries each month on the newsgroups and then they get a very special recognition on the digitalmars site?
>>>
>>> Yes, a monthly competition like this is also a good idea.
>>>
>>> We have several authors on the list maybe we can get them to donate a copy of one of there books for a first prize.
>>  I've thought about cash prizes and contests. I just had the nagging feeling that the result would be a circus rather than serious development.
>
> A library contest would be far too much work _both_ for the administrators and for the programmers.
>
> For any non-trivial stuff it would necessarily drag out over months (if not quarters), and get psychologically diluted -- especially knowing that most (not all) of the contestants are of the breed "get quickly enthused and equally quickly disinterested". (Just look at the number of started projects at, say dsource, versus actual progress in most of them.)
>
> A bit more demanding on the "establishment", but a lot more rewarding for our end goal would be to have contests on smaller units! Such would be individual classes, maybe groups of functions, or even very-narrow-purpose libraries. There should also be a separate, on-going series for single functions!!
>
> The administration would be more work, granted. And choosing the contest items would require much more work if we wanted to stay determined on keeping in mind the end-goals and overall progress of the D effort.


I agree. Implementing stuff usually takes a lot more time than you originally thought it would.

And what if we end up with 10 good versions of a single library? If we keep just one (or two), there will be a lot of work 'wasted'.

I think the most important thing conserning libraries is their API, not how they are internally implemented. Of course, the API and the implementation are usually intertwined, and you have think what may be needed in the future too. Library should be simple and easy to use, yet flexible and extendable. That's not an easy task, I think. ;)

So maybe we should have contents on APIs first. When we got the base structure right, we can make competitions on parts (e.g. functions, classes) that should be efficient, or hard to implement. Bulk (trivial) stuff can be implemented outside the competitions later. Also, API implementations should include documentation.