Hi!

I have made some sort of proposal to how the
D Standard Library Group (DSLG) should be organized.

The group and it's organization is specified in 'grouprules'.
The responsibilities are specified in 'responsibilities'.
A (very short) style guide is presented in 'styleguide'.

When it comes to group members, I would suggest;
  In the main group: Burton Radons,
                     Ben Hinkle,
                     Sean L. Palmer,
                     Justin Calvarese,
                     Andy Friesen and
                     myself :) (You're free to suggest
                                someone else.)
  Review members:    Walter Bright and
                     Matthew Wilson

My suggestion will leave almost no power over phobos to
Walter. In the long run I believe it is necessary and
probably good in the short run so he can concentrate on
the compiler and language itself.

Further, is it possible to use opend.org for this group? Does it have a CVS repository?

Well, please discuss.

Lars Ivar Igesund

my 2 cents: I know you mean well but I don't think this group is needed (at
the moment).

> When it comes to group members, I would suggest;
>   In the main group: Burton Radons,

>                      Ben Hinkle,

ack. Can I unsuggest myself? Not to be ungrateful but I haven't put *any* thought into where phobos should go. I know I'm working on getting the GCC port and it would be nice to keep the standard library portable but I think people are generally aware of the issues and the design decisions made so far seem very reasonable w.r.t. portability.

What are the general proposals for changes to Phobos? I haven't been paying that much attention.

I seem to recall Matthew saying he was going to tackle DTL (which I just assumed was the D equivalent to STL). This would be a big part of any standard library and I assumed it would go in phobos eventually. I also seem to recall Walter saying he'd like to keep any GUI toolkit separate from the standard library, which makes sense to me, too.

>                      Sean L. Palmer,
>                      Justin Calvarese,
>                      Andy Friesen and
>                      myself :) (You're free to suggest
>                                 someone else.)
>   Review members:    Walter Bright and
>                      Matthew Wilson
>
> My suggestion will leave almost no power over phobos to
> Walter. In the long run I believe it is necessary and
> probably good in the short run so he can concentrate on
> the compiler and language itself.

Personally I'd like Walter and Matthew to be heavily involved in the design. I trust them to "do the right thing". Since Walter has driven Phobos this far I'm nervous about switching drivers - especially to a gaggle of drivers. Besides, this really is his "baby" and if he wants help with Phobos I'm comfortable waiting until he asks for it.

Eventually you are probably right that some independent group should take ownership. I'm just not convinced any group we could muster at the moment would do a better job than the current setup of Walter driving and us shouting directions from the back seat. Imagine how it feels to him reading over and over "Are we there yet? How much longer? I gotta pee."

-Ben

> Further, is it possible to use opend.org for this group? Does it have a CVS repository?
>
> Well, please discuss.
>
> Lars Ivar Igesund
>

> Personally I'd like Walter and Matthew to be heavily involved in the
design.
> I trust them to "do the right thing". Since Walter has driven Phobos this far I'm nervous about switching drivers - especially to a gaggle of
drivers.
> Besides, this really is his "baby" and if he wants help with Phobos I'm comfortable waiting until he asks for it.

I agree with your opinion.

 I'm just not convinced any group we could muster at the moment
> would do a better job than the current setup of Walter driving and us shouting directions from the back seat. Imagine how it feels to him
reading
> over and over "Are we there yet? How much longer? I gotta pee."

and here I agree again.

No offence meant to the guys that have been suggested as "members", as Im REAL sure they know a hell of a lot more than I do about D.

But you must agree this is Walter's domain and he is damn good at it, so why risk it, when it is about to become real big?

Phill.

While I think its a good idea and it is definitely time to speed up phobos development , I don't know that something so bureaucratic is necessary ( or likely to be accepted ).

We do however need a way to address issues with phobos as they come up ,
recently the eof() issue (
http://www.digitalmars.com/drn-bin/wwwnews?D/22760 ) , the Win98 GC
misbehaving ( http://www.digitalmars.com/drn-bin/wwwnews?D/22303 ) , and
even possibly having a choice between garbage collectors (
http://www.digitalmars.com/drn-bin/wwwnews?D/23097 ) etc...

Perhaps let Matthew filter out requests for changes and accompanying patches( through a simple HTML form on digitalmars ) , and let Walter have the final approval ?

Right not there is no direct way to address these issues , we just throw it up here in hopes Walter will read it / respond , and often times thats unfulfilling because you never get an answer , and you don't know if he saw it and refused , or didn't see it etc...

Its a tricky subject , but one that I thing needs to be addressed

IMO ( everyone's got em :) )
C


"Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:bvmk6r$2jto$1@digitaldaemon.com...
> Hi!
>
> I have made some sort of proposal to how the
> D Standard Library Group (DSLG) should be organized.
>
> The group and it's organization is specified in 'grouprules'.
> The responsibilities are specified in 'responsibilities'.
> A (very short) style guide is presented in 'styleguide'.
>
> When it comes to group members, I would suggest;
>   In the main group: Burton Radons,
>                      Ben Hinkle,
>                      Sean L. Palmer,
>                      Justin Calvarese,
>                      Andy Friesen and
>                      myself :) (You're free to suggest
>                                 someone else.)
>   Review members:    Walter Bright and
>                      Matthew Wilson
>
> My suggestion will leave almost no power over phobos to
> Walter. In the long run I believe it is necessary and
> probably good in the short run so he can concentrate on
> the compiler and language itself.
>
> Further, is it possible to use opend.org for this group? Does it have a CVS repository?
>
> Well, please discuss.
>
> Lars Ivar Igesund
>


----------------------------------------------------------------------------
----


> Mandate:
>  Manage the D standard library interface (see responsibilities).
>  Provide a sample implementation.
>
> Members:
>  The group should have 6 full members having one vote each.
>  In addition, two review members should have half a vote each,
>  totalling 7 votes. No member can set down a veto.
>  The main members should be elected by the community (somehow).
>  The review members should be Walter and Matthew(?) (IMHO).
>  The main members sit in the group for 18 months each. 2 are
>  replaced every 6 months. (This means that of the first six,
>  two must leave after 6 months, and two after 12 months.)
>  Members can only sit in the group for two consecutive periods
>  (then there must be at least one period's pause).
>  The review members can sit as long as they want.
>
> Changes:
>  An API change needs at least 6 votes.
>  Patches to the implementation must be audited and approved by
>  at least three members.
>  Everyone can propose changes, but unless they are documented
>  and well founded, they will be rejected no matter what.
>
>


----------------------------------------------------------------------------
----


> 1. Design of API
>    - The API decided upon by the group must be the
>       standard that all vendors conform to.
>    - The API should be feature complete with regard
>       to basic operations needed in modern applications
>    - Last point means that the API might change with time
>       as long as revision numbers can be used to make sure
>       that as few applications as possible are broken as
>       few times as possible.
>    - The group must strive for a stable API (as long as it
>       don't hinder new technologies).
>    - The group must strive for an API without bloat.
>    - All D compiler vendors must distribute a standard
>       library implementing this API.
>    - The API should be consistent over different platforms.
>    - The API must follow the API style guide.
>    - The API should not be just a wrapper for C APIs. As an
>       example, the Windows API should be provided in own
>       (preferebly standard) packages and shipped with the
>       compilers (like the Windows headers are with C
>       compilers).
>
> 2. Mantainer of sample implementation
>    - The group should mantain a sample implementation
>       (the first iteration should probably be Phobos).
>    - The sample implementation should be as stable as possible.
>    - The sample implementation should strive for correctness
>       before optimizations.
>    - The implementation should be as independent as possible.
>    - The implementation should follow the code style guide.
>


----------------------------------------------------------------------------
----


> 1. API style guide
>   - The API should be loosely coupled.
>   - Bloat must be avoided.
>   - Function names should be understandable.
>   - Function names should have each word except the first capitalized.
>
> 2. Code style guide
>   - In my opinion, Walter's style guide is mostly good enough.
>

Ben Hinkle wrote:
> my 2 cents: I know you mean well but I don't think this group is needed (at
> the moment).

Hmm, well I don't agree. :)

> 
> 
>>When it comes to group members, I would suggest;
>>  In the main group: Burton Radons,
> 
> 
>>                     Ben Hinkle,
> 
> 
> ack. Can I unsuggest myself?

Of course :)

> What are the general proposals for changes to Phobos? I haven't been paying that much attention.

Not really of relevance in this discussion, IMHO, although there are several issues that needs to be resolved, both with regard to the already existing API, the implementation of it and missing features. And documentation.

>>                     Sean L. Palmer,
>>                     Justin Calvarese,
>>                     Andy Friesen and
>>                     myself :) (You're free to suggest
>>                                someone else.)
>>  Review members:    Walter Bright and
>>                     Matthew Wilson
>>
>>My suggestion will leave almost no power over phobos to
>>Walter. In the long run I believe it is necessary and
>>probably good in the short run so he can concentrate on
>>the compiler and language itself.
> 
> Personally I'd like Walter and Matthew to be heavily involved in the design. I trust them to "do the right thing". Since Walter has driven Phobos this far I'm nervous about switching drivers - especially to a gaggle of drivers. Besides, this really is his "baby" and if he wants help with Phobos I'm comfortable waiting until he asks for it.

Walter has made some guidelines to how he thinks phobos
should be organized (see the attached post), and as I
understand it, he asked for help. He don't have the time
to concentrate on phobos in addition to the language and
compiler.

> Eventually you are probably right that some independent group should take ownership. I'm just not convinced any group we could muster at the moment would do a better job than the current setup of Walter driving and us shouting directions from the back seat. Imagine how it feels to him reading over and over "Are we there yet? How much longer? I gotta pee."

I believe that any group we could muster would be able to do
*something*, which is more than Walter (sorry to say this) has
done in a long while (zlib being the exception confirming the
rule.) As long as the guidelines for the group is strict, I don't
think that it will take too many wrong directions. Personally I
wouldn't mind Walter being able to veto changes, but to pipe
all changes through him would destroy any momentum.

And at last, and I hope you didn't mean to, but I find your argumentation somewhat belittling.

Lars Ivar Igesund

Just to let you know I've read it, but am frazzled atm. Give me a few days, and let's hear some more opinions, and then I'll shoot off my thoughts.

I know it's not like me to hang back when there's an opportunity for put forth my half-considered ideas, but I think this is an important issue, and deserves my time and respect before I post thoughts/decisions.

"Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:bvmk6r$2jto$1@digitaldaemon.com...
> Hi!
>
> I have made some sort of proposal to how the
> D Standard Library Group (DSLG) should be organized.
>
> The group and it's organization is specified in 'grouprules'.
> The responsibilities are specified in 'responsibilities'.
> A (very short) style guide is presented in 'styleguide'.
>
> When it comes to group members, I would suggest;
>   In the main group: Burton Radons,
>                      Ben Hinkle,
>                      Sean L. Palmer,
>                      Justin Calvarese,
>                      Andy Friesen and
>                      myself :) (You're free to suggest
>                                 someone else.)
>   Review members:    Walter Bright and
>                      Matthew Wilson
>
> My suggestion will leave almost no power over phobos to
> Walter. In the long run I believe it is necessary and
> probably good in the short run so he can concentrate on
> the compiler and language itself.
>
> Further, is it possible to use opend.org for this group? Does it have a CVS repository?
>
> Well, please discuss.
>
> Lars Ivar Igesund
>


----------------------------------------------------------------------------
----


> Mandate:
>  Manage the D standard library interface (see responsibilities).
>  Provide a sample implementation.
>
> Members:
>  The group should have 6 full members having one vote each.
>  In addition, two review members should have half a vote each,
>  totalling 7 votes. No member can set down a veto.
>  The main members should be elected by the community (somehow).
>  The review members should be Walter and Matthew(?) (IMHO).
>  The main members sit in the group for 18 months each. 2 are
>  replaced every 6 months. (This means that of the first six,
>  two must leave after 6 months, and two after 12 months.)
>  Members can only sit in the group for two consecutive periods
>  (then there must be at least one period's pause).
>  The review members can sit as long as they want.
>
> Changes:
>  An API change needs at least 6 votes.
>  Patches to the implementation must be audited and approved by
>  at least three members.
>  Everyone can propose changes, but unless they are documented
>  and well founded, they will be rejected no matter what.
>
>


----------------------------------------------------------------------------
----


> 1. Design of API
>    - The API decided upon by the group must be the
>       standard that all vendors conform to.
>    - The API should be feature complete with regard
>       to basic operations needed in modern applications
>    - Last point means that the API might change with time
>       as long as revision numbers can be used to make sure
>       that as few applications as possible are broken as
>       few times as possible.
>    - The group must strive for a stable API (as long as it
>       don't hinder new technologies).
>    - The group must strive for an API without bloat.
>    - All D compiler vendors must distribute a standard
>       library implementing this API.
>    - The API should be consistent over different platforms.
>    - The API must follow the API style guide.
>    - The API should not be just a wrapper for C APIs. As an
>       example, the Windows API should be provided in own
>       (preferebly standard) packages and shipped with the
>       compilers (like the Windows headers are with C
>       compilers).
>
> 2. Mantainer of sample implementation
>    - The group should mantain a sample implementation
>       (the first iteration should probably be Phobos).
>    - The sample implementation should be as stable as possible.
>    - The sample implementation should strive for correctness
>       before optimizations.
>    - The implementation should be as independent as possible.
>    - The implementation should follow the code style guide.
>


----------------------------------------------------------------------------
----


> 1. API style guide
>   - The API should be loosely coupled.
>   - Bloat must be avoided.
>   - Function names should be understandable.
>   - Function names should have each word except the first capitalized.
>
> 2. Code style guide
>   - In my opinion, Walter's style guide is mostly good enough.
>

> And at last, and I hope you didn't mean to, but I find your argumentation somewhat belittling.

Sorry about that. I didn't intend any offense. Your proposal is well thought
out and I didn't mean to belittle anyone.
-Ben

Ben Hinkle wrote:
>>And at last, and I hope you didn't mean to, but I find your
>>argumentation somewhat belittling.
> 
> 
> Sorry about that. I didn't intend any offense. Your proposal is well thought
> out and I didn't mean to belittle anyone.
> -Ben
> 

Good, good! Sorry to subject you to such charges.

Lars Ivar Igesund

Phill wrote:

> But you must agree this is Walter's domain and he is damn good at it, so

Not according to the man himself (see my attachment in my answer to
Ben).

Lars Ivar Igesund

C wrote:

> While I think its a good idea and it is definitely time to speed up phobos
> development , I don't know that something so bureaucratic is necessary ( or
> likely to be accepted ).

I'm of the opinion (you might have noticed already ...) that a
bureaucratic (and democratic) approach is better than a dictatorship.

> Perhaps let Matthew filter out requests for changes and accompanying
> patches( through a simple HTML form on digitalmars ) , and let Walter have
> the final approval ?

Relying on one person is probably the least efficient possibility, at
least when that person is busy with something else. Probably, members
of the group should have less possibility to veto by not voting, or
voting against.
If Walter should have the right to veto, it should be after a suggested
change has been through the mill of the group (hopefully this can be
a efficient process.), leaving a as little burden on him as possible.

Lars Ivar Igesund