Re: Continued RFC process

2000-10-11 Thread Piers Cawley

Dan Sugalski [EMAIL PROTECTED] writes:

 At 07:09 PM 10/10/00 -0600, Nathan Torkington wrote:
 Dan Sugalski writes:
   "General consensus" is best, but that can't be guaranteed. "Consensus of
   the ruling council" is more attainable, but there's that whole "ruling
   council" thing to contend with. "What Larry says" is best, but what happens
 
   if he doesn't, or gets hit by a bus at some point?
 
 In terms of ongoing maintenance, I'd say that the teams will act as
 the Ruling Council.  When teams get pissed off with the release
 manager, then the leader will have to go.  When members of a team
 can't work together, then the release manager works with them to
 figure out where the problem is and fix it.  This might be everything
 from "play nice" to hiring a hitman :-)
 
 Works. We still have those Quantum Ninja that we're holding in reserve for
 Damian... :)

Yeah, but be careful, he could pull and Egan on them and Cantor Dust
'em off.

-- 
Piers




Re: Continued RFC process

2000-10-11 Thread Piers Cawley

Jonathan Scott Duff [EMAIL PROTECTED] writes:

 On Tue, Oct 10, 2000 at 03:11:54pm -0500, David Grove wrote:
  They think I'm paranoid and the only one who sees the danger.
  Relatively few people speak openly about it for fear of getting the
  same beatings I get on a regular basis.  Frankly I think it's
  important for these guys just to realize that other people are sitting
  back and watching, with unexpressed interests.
 
 Perhaps it's just me, but I don't see a problem yet.  If Perl were
 somehow being "taken over", then I expect the Perl community (at the
 very least, one David Grove :-) to be up in arms about it.  

He's already up in arms about it and it's not happening. 

-- 
Piers




Re: Continued RFC process

2000-10-11 Thread Simon Cozens

On Tue, Oct 10, 2000 at 11:08:36PM -0500, J. David Blackstone wrote:
   I repeat my suggestion from a couple of days ago that someone author
 a document on "how to politely fork your own development effort,"

I happen to be in the middle of an article on this very subject.

-- 
"The elder gods went to Suggoth and all I got was this lousy T-shirt."



Re: Continued RFC process

2000-10-11 Thread John Porter

Tad McClellan wrote:
  
  I was sort of hoping to go with Perl 6 Secred Decoder Rings, but a 
   ^   ^
 
 Maybe it's not even a typo.

It's the past participle of "secre", although what that
means, I am not permitted to divulge.


 Is it an attempt to create a new word so that you can be
 enshrined in etymologies throughout the world?

Oh, quit your whinging!   :-)

-- 
John Porter




Re: Continued RFC process

2000-10-11 Thread John Porter

J. David Blackstone wrote:
 
 I'm talking a pair of lists for each working
 group/committee/whatever-you-want-to-call it.

Hm, kinda like the clp.misc/clp.moderated duality...

-- 
John Porter




Re: Continued RFC process

2000-10-11 Thread Stephen Zander

 "Dan" == Dan Sugalski [EMAIL PROTECTED] writes:
Dan what happens if for some reason I turn into a raving nutter
Dan and won't go?

What you mean "will", Kimosabi? :)

-- 
Stephen

"Farcical aquatic ceremonies are no basis for a system of government!"



RE: Continued RFC process

2000-10-11 Thread Glen


--- David Grove [EMAIL PROTECTED] wrote:
 How do we allow the core developers some peace, while giving the community
 FREE 
 voice? Free being, if it's perl related, it's valid. Free by any other 
 definition is also a farce.

IMHO, the fact that this list is not in the midst of a huge flame war over your
e-mails and the fact that the so-called "elite" are responding constructively
to your e-mails shows me that the community is at least heading in the right
direction.

Glen.


__
Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/



RE: Continued RFC process

2000-10-11 Thread Dave Rolsky

On Wed, 11 Oct 2000, Glen wrote:

 IMHO, the fact that this list is not in the midst of a huge flame war over your
 e-mails and the fact that the so-called "elite" are responding constructively
 to your e-mails shows me that the community is at least heading in the right
 direction.

The community is already fine (not perfect, but nothing is).  It does not
need to go in a new (or 'right') direction.  The fact that there is no
flame war is a testament to the patience, tolerance, and maturity of those
people who've put so much time and effort into Perl5, often in the face of
sheer insanity.


-dave

/*==
www.urth.org
We await the New Sun
==*/




RE: Continued RFC process

2000-10-11 Thread Bryan C . Warnock

On Tue, 10 Oct 2000, David Grove wrote:
 Absolutely it's appropriate. They think I'm paranoid and the only one who sees 
 the danger. Relatively few people speak openly about it for fear of getting the 
 same beatings I get on a regular basis. Frankly I think it's important for 
 these guys just to realize that other people are sitting back and watching, 
 with unexpressed interests.

Fear?  Sure, sort of.  I know that I have deliberately withheld the
names of my last three employers, and have resorted to mail forwarding,
which, by the way, David also doesn't like, and gets me filtered out by
a significant bunch of peoples' readers.

Why?  Lessee...

1. I'm subverting Perl for my company's benefit, but my company doesn't
want anyone to know that.

2. My company wants to make absolutely clear that my involvement with
Perl is of my own accord, and that my company has no stake in its
success or failure, and has forbidden any association.  (Even with the
standard "no involvement" caveats.)

3. Personal choice.  It's none of your business.  Arguments like that.

4. Fear that my relationship with my employer would be interpreted as
anything other than "I work for so and so."  (Part of number 4 comes
from the inability of some folks to just handle the truth.)

How do you convince someone that 2, 3, or 4 is not 1?

Luckily, my new company is encouraging me to use their resources and
drop their name as much as possible, so I will probably be switching
at some point, which should help the above filtering problem.

 -- 
Bryan C. Warnock ([EMAIL PROTECTED])



Re: Continued RFC process

2000-10-10 Thread Bart Lateur

On Mon, 09 Oct 2000 21:39:27 -0500, J. David Blackstone wrote:

  If enough people really feel that worried about Perl falling into
the hands of a few, then something like this might be a good idea.

I am quite happy with Perl as it is now, so having no say in how it
should evolve, doesn't really worry me. I'll most likely stay happy with
Perl.

However, if Microsoft or whoever were to somehow
to gain total control of Perl, couldn't somebody just go off and
create a Perl-compatible p*rl, according to the GPL and/or Artistic
License?

Now there is something that, at least slightly, worries me. I don't
think that "the Real Perl" should *ever* need to go search fo a new
name. Such hostile takeovers should simply be impossible. That's why I
like the fact that Laryy remains in absolute control.

-- 
Bart.



RE: Continued RFC process

2000-10-10 Thread Andy Dougherty

On Mon, 9 Oct 2000, David Grove wrote:

 On Monday, October 09, 2000 7:12 PM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] 
 wrote:

 How about an open, crossplatform mailing list for issues, with a
 mechanism on perl.org for public voting on larger issues.

In a volunteer organization, you can't reliably translate votes on issues
into action.

To be concrete, consider a perl5 example.  Suppose that there was a vote
to change from metaconfig to autoconf for perl5.  Suppose further that the
current Configure maintainer didn't know anything about autoconf and
judged himself unable to complete the task in any timely manner.  What
would happen next?  Probably nothing, unless an autoconf champion steped
forward and volunteered to take over configuration issues.  But in that
case, what was the point of the vote?  At any time, _anyone_ can step
forward and champion a cause.  If he or she makes a good case and
implements it well[*], then it will probably be adopted.

Similar concerns hold for other issues.  Without a champion to implement
the changes, nothing is likely to happen.  With a champion, no vote is
needed--the champion can just go ahead and try to do it.

There are, of course, cases where things are not clear cut.  Suppose, for
example, that someone proposes and implements a feature (e.g. safe
signals) but it has a drawback (e.g. 10% slowdown).  Should that feature
be included in perl?  That's a tough question involving difficult
tradeoffs.  It's not at all obvious to me that voting is a better way to
resolve such issues than the current process of allowing the pumpkin
holder to decide.

[*]Of course "implements it well" is a subjective criterion, but one
important aspect of it ought to be a reasonable plan for the long term
maintenance of the feature (usually the champion saying "I'll do it.")

-- 
Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042




RE: Continued RFC process

2000-10-10 Thread Andy Dougherty

On Mon, 9 Oct 2000, Nathan Torkington wrote:

 Closed-for-posting mailing lists that are publically readable is the
 best suggestion we've had to meet these ends so far.
 
 Anyone have better suggestions?

Just that it not be *too* hard to get on the closed lists (and,
symmetrically, that it not be *too* hard for the list chair to bounce
someone *off* the list if that person is judged to be persistently and
seriously damaging to the list).

I'm not suggesting anything formal here--in fact I think it's best if we
make it up as we go along--just that we record our overall expectation
that we're reasonable people trying to balance conflicting needs in a
reasonable way.

Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042




Re: Continued RFC process

2000-10-10 Thread Dan Sugalski

At 08:20 AM 10/10/00 -0700, Nathan Wiger wrote:
Andy Dougherty wrote:
 
  On Mon, 9 Oct 2000, Nathan Torkington wrote:
 
   Closed-for-posting mailing lists that are publically readable is the
   best suggestion we've had to meet these ends so far.
  
   Anyone have better suggestions?
 
  Just that it not be *too* hard to get on the closed lists (and,
  symmetrically, that it not be *too* hard for the list chair to bounce
  someone *off* the list if that person is judged to be persistently and
  seriously damaging to the list).

Yep, this is my only concern. It should be reasonably easy to say "I
really want to help" and get on the closed lists. Perhaps the best way
of making sure the lists don't bloat into "everyone has an opinion"
lists is to require that *all* members contribute code to that list's
purpose. If you're on the list, you _must_ program. So, if you really
want to help with async i/o, that's fine, join -internals-io, but be
aware that if you aren't actively contributing code you'll be dropped.

I'd rather not limit the subscriptions to people that are coding. We need 
as many folks with good design skills as we can muster, and I'd rather not 
require them to also submit code. The two skills (coding and designing) are 
separate ones--good coders can (and often are) lousy designers, while good 
designers aren't necessarily good coders. Good design skills are also 
significantly scarcer than good coding skills.

I also don't want to lose the folks with experience in an area just because 
they don't have time to do code either. Someone like Graham, Tim, or Alan 
might well be able to drop a mail message or six in between other things 
while still not having the time (or interest) to sit down and actually 
write a chunk of code.

That pretty much leaves us with "wing it" as a methodology, but that's 
probably OK for now.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk




Re: Continued RFC process

2000-10-10 Thread Uri Guttman

 "DS" == Dan Sugalski [EMAIL PROTECTED] writes:

  DS Read-only access is a must for any list like this, and with more
  DS than just a web archive. I'm sure Ask will set things up so anyone
  DS that likes can subscribe to the read-only version of the list.

that was in my original post about this. ezmlm can allow open
subscription to all and have a fixed list of allowed posters or it can
be moderated so that the list regulars can get it and sometimes others
with useful input can get in. i think moderation might work unless the
volume gets heavy. you can also have multiple moderators (consisting of
the core of the list) which makes it easier to manage.

but having public read only access is vital. you never know when an
outside eye will see something that the insiders are missing
(forests/tree).

the lists should also be archived in the usual ways. having search
functions (on the web?) would be a good addition. development lists many
times will note an idea early on and forget it later. i have refound
some good nuggets by looking through old email.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com



Re: Continued RFC process

2000-10-10 Thread Jonathan Scott Duff

David Grove wrote:
 Read-only and carefully censored lists are irrelevant to the goals of
 Perl 6's giving voice to the perl community.  They lead us right back
 where we were before, with a core group free to sit back unchallenged
 on their complacency and let Perl go to rot.  

What does "unchallenged on their complacency" mean?  In the world of
OSS, those that have time and inclination design or code things they
find interesting.  If no one champions a cause, nothing happens.  It
sounds like you are saying that if the community wants Feature X and no
one steps up to write the code to add Feature X to perl, then "the
community" should somehow be able to force the developers that are
already working on some aspect of perl to add Feature X.

 However, I don't agree that the developers should be able to ignore
 the community within a closed-off little clique.

What community needs do you feel are being ignored?

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]



Re: Continued RFC process

2000-10-10 Thread Stephen Zander

 "Dan" == Dan Sugalski [EMAIL PROTECTED] writes:
Dan A better analogy is that Larry's the Bishop and Chief
Dan Architect, while the rest of us are engineers, sectional
Dan architects, artisans, craftsmen, journeymen, and apprentices,
Dan working to build up a cathedral. (And yes, I do mean this
Dan analogy in the way you likely think I do, amongst other ways)

Ooohh, Freemasonry comes to Perl.  Can I make up the handshake? :)

-- 
Stephen

"And what do we burn apart from witches?"... "More witches!"



Re: Continued RFC process

2000-10-10 Thread Dave Storrs

Is anyone here familiar with the behind-the-scenes process and politics of
the Linux development community?

If I understand it correctly (and I'm not sure I have the details right),
when Linux was being developed, Linus came up with a skeletal OS based off
of MINIX, then he turned it loose.  People volunteered bits of code which
Linus integrated into the OS.  As the thing snowballed, Linus couldn't
handle the volume, so he chose a group of lieutenants who also had commit
authority.  Now, I'm not sure where the planning came from...was there a
specific website or elist or whatever where Linus said "ok, we'd like a
TCP/IP stack that has the following interface?"  Or what?

Whatever they did worked, and I haven't heard anything to suggest that the
Linux community feels excluded...is there some way we can duplicate/adapt
their process so that we can simultaneously put to rest both David Grove's
concerns about elitism and Dan Sugalski's concerns about lack of planning?


Dave




RE: Continued RFC process

2000-10-10 Thread Dave Storrs



On Mon, 9 Oct 2000, Nathan Torkington wrote:

 Closed-for-posting mailing lists that are publically readable is the
 best suggestion we've had to meet these ends so far.
 
 Anyone have better suggestions?

I don't know that this is _better_, but...perhaps we could have
the lists that you suggest, but also have separate, publicly postable,
lists where anyone could comment.  If one person from the design committee
would be willing to read these public lists and interact with the people
there, saying "that's a good idea, we'll use it" or (probably more common)
"we'd like to do that, but we can't for reasons XYZ," that would go a long
way towards making the community feel invovled.  Perhaps this duty could
rotate, so that various design-committee voices would be heard on the
outside.

Dave





RE: Continued RFC process

2000-10-10 Thread David Grove

On Tuesday, October 10, 2000 10:51 AM, Dan Sugalski [SMTP:[EMAIL PROTECTED]] wrote:
 Yep, this is my only concern. It should be reasonably easy to say "I
 really want to help" and get on the closed lists. Perhaps the best way
 of making sure the lists don't bloat into "everyone has an opinion"
 lists is to require that *all* members contribute code to that list's
 purpose. If you're on the list, you _must_ program. So, if you really
 want to help with async i/o, that's fine, join -internals-io, but be
 aware that if you aren't actively contributing code you'll be dropped.

 I'd rather not limit the subscriptions to people that are coding. We need
 as many folks with good design skills as we can muster, and I'd rather not
 require them to also submit code. The two skills (coding and designing) are
 separate ones--good coders can (and often are) lousy designers, while good
 designers aren't necessarily good coders. Good design skills are also
 significantly scarcer than good coding skills.

 I also don't want to lose the folks with experience in an area just because
 they don't have time to do code either. Someone like Graham, Tim, or Alan
 might well be able to drop a mail message or six in between other things
 while still not having the time (or interest) to sit down and actually
 write a chunk of code.

 That pretty much leaves us with "wing it" as a methodology, but that's
 probably OK for now.

Hmmm. Impressive... logic and fairness. I'm sorry I'm just not used to that in 
discussing this issue.

However, what opportunities can we have for checks/balances? Surely you can see 
that something should be in place to prevent the type of mess we're in right 
now, no? (forest/trees)

Sometimes I feel like an advocate of "Save the Whales". People have heard it so 
many times, they just get tired of it. Doesn't mean that in 2307 the space 
probe won't destroy our planet unless Kirk goes back in time to ... no wait, 
lost my train of thought.

Sometimes I feel like an advocate of "Save the Rain Forest". We all know if we 
don't, we're dead. We still get annoyed by people shouting "Save the Rain 
Forest" and want to lock them out of our lives, because we're selfish and 
_want_ to drive our cars. Hmmm, I think that's quite a decent analogy.





Re: Continued RFC process

2000-10-10 Thread Will Coleda - IMG

Nathan Wiger wrote:
 I was going to suggest a criteria for initial membership of having
 authored at least a CPAN module or core patch, but I'm not sure. It
 seems reasonable that someone shouldn't be programming core if they
 haven't really done anything big in Perl before (and given it back), but
 I'm not sure if this is too strict.

I happen to be someone who -hasn't- given anything back to Perl (yet?).
Here's my 2c.

(a) This will have the effect of shutting out folks that may have
talent.
(b) Just because someone has contributed something to CPAN doesn't mean
it was of quality.

It seems like this would be (sorry if I'm putting words in your mouth,
David) exactly the kind of thing David would have a problem with:
exclusionary based on previous perl-formance.

That being said, I agree you need -some- kind of measurement of how
people can/have contribute... I think that it makes sense for the
-chair- of a particular section be someone with perl experience, and if
they have "newbies" that can design and code, so be it.

Regards.



Re: Continued RFC process

2000-10-10 Thread Simon Cozens

On Tue, Oct 10, 2000 at 12:34:33PM -0700, Dave Storrs wrote:
 is there some way we can duplicate/adapt
 their process so that we can simultaneously put to rest both David Grove's
 concerns about elitism and Dan Sugalski's concerns about lack of planning?

No.

-- 
Everything that can ever be invented has been invented 
- Charles H. Duell, Commisioner of U.S. Patents, 1899.



RE: Continued RFC process

2000-10-10 Thread David Grove

On Tuesday, October 10, 2000 1:26 PM, Andy Dougherty 
[SMTP:[EMAIL PROTECTED]] wrote:
 [An offlist request for clarification, though I invite you to follow-up to
 the perl6-meta list if you deem appropriate]

Absolutely it's appropriate. They think I'm paranoid and the only one who sees 
the danger. Relatively few people speak openly about it for fear of getting the 
same beatings I get on a regular basis. Frankly I think it's important for 
these guys just to realize that other people are sitting back and watching, 
with unexpressed interests.

 On Tue, 10 Oct 2000, David Grove wrote:

  How do we allow the core developers some peace, while giving the community
  FREE
  voice?

 Apart from the voting idea, do you have any other specific suggestions?
 The dilemma you cite is indeed real.

The problem with voting is indeed just as has been described. It can be faked. 
Who was it... deja.com... some search engine has votings on it on a regular 
basis. It was basically fair until a certain point. For several months, FreeBSD 
and Linux topped the charts, until suddenly, in about a week, NT went from the 
total bottom to the total top. I think the subject was something like "secure 
server O/S". Similar things happened to VB in different ratings... started out 
sucking in the majority vote (bottom of the list by a huge margin), then 
suddenly it sprang up.

Perhaps, then, there should be one more officer, chosen by Larry himself. This 
person would be responsible for collecting public opinions and representing 
them to the developer group, who needs to follow that guidance as long as 
they're technically capable. (Obviously, because of my big mouth and cynical 
nature, I'm not qualified, so I'm not suggesting myself.) This person must be 
impeachable, or at least, know when to step down when the time comes, and be 
trusted to know when to do so and actually do it. This person should also 
determine the timing of releases, or agree to the timing based on public 
opinion. No more of this releasing versions before they're ready or withholding 
modules. If we can't have a stable perl, we won't have a perl at all. Don't 
think that our current "information officer" is capable of accurately or 
faithfully filling this role, you'd be off by several hundred miles.





Re: Continued RFC process

2000-10-10 Thread Nathan Wiger

Dan Sugalski wrote:
 
   Just that it not be *too* hard to get on the closed lists 
 
 Yep, this is my only concern. It should be reasonably easy to say "I
 really want to help" and get on the closed lists. Perhaps the best way
 of making sure the lists don't bloat into "everyone has an opinion"
 lists is to require that *all* members contribute code to that list's
 purpose. If you're on the list, you _must_ program.

 I'd rather not limit the subscriptions to people that are coding. We need
 as many folks with good design skills as we can muster, and I'd rather not
 require them to also submit code. The two skills (coding and designing) are
 separate ones--good coders can (and often are) lousy designers, while good
 designers aren't necessarily good coders. Good design skills are also
 significantly scarcer than good coding skills.

I think we're talking about two different things, but I do agree with
you.

My concern is that there needs to be *some* type of criteria for who can
join a list, which is published, easily measured, and widely-understood.
One part of Dave Grove's concerns I do agree with is the _potential_
(not certainty) for lists to become ad hoc, exclusionary entities. If
list membership is based on intangible "this guy's cool" measurements,
then there is the risk of a "good old boys" mentality. I have seen this
before at my former employer (hence why I left) and it's not pretty. :-)

There is the possibility of separate lists. Why not have -internals be
the top-level list still? Anyone can join, anyone can comment, etc. On
the spawning of the -internals-io sublist, though, only concerned
developers should join. If there comes to be an impass, they can post a
summary on -internals. "Ok, there's two ways we're thinking about this,
whatd'ya think?" It could make things more efficient, and allow
measurable list membership (anyone on -internals, coders on
-internals-sublist).

Anyways, I'm not trying to push my idea per se, but I do think there
needs to be a widely-known criteria for list membership if it's going to
be restricted. If it's ad hoc, it will likely end up exclusionary in
some way - even if there are counterefforts - because people are, by
nature, "clique-ish". We all like hanging out with people we know. So I
think we need some type of "policy" in place - even if it's a very
flexible, relaxed policy - to establish who can join lists. Otherwise we
risk arbitrary decisions and exclusivity.

I disagree a highly-bureaucratic, checks-and-balances approach is what
we need. However, I do think a 2-3 sentence statement of purpose and
membership for sublists could solve many problems. Similar to what we
have with -language, but fleshed out more.

-Nate



Re: Continued RFC process

2000-10-10 Thread Simon Cozens

On Tue, Oct 10, 2000 at 03:11:54PM -0500, David Grove wrote:
 Perhaps, then, there should be one more officer, chosen by Larry himself.
 This person would be responsible for collecting public opinions and
 representing them to the developer group, who needs to follow that guidance
 as long as they're technically capable.

Well, we have two. One for the users, and one for the corporates.

 This person should also determine the timing of releases, or agree to the
 timing based on public opinion. No more of this releasing versions before
 they're ready or withholding modules. 

This is screamingly insane. The people who do the development are the people
who are best placed to know when it's time to ship.

Consider:
"Public Opinion": Hey, we need Perl 6 stable in three weeks.
Coders: But, uhm, we haven't started coding yet.

No, no, no, no. He who leads the development *must* lead the release schedule.
This is open source, David. You might have heard of it.

 Don't think that our current "information officer" is capable of accurately
 or faithfully filling this role, you'd be off by several hundred miles.

You kind of have to justify statements like that, I'm afraid.
 
-- 
buf[hdr[0]] = 0;/* unbelievably lazy ken (twit) */  - Andrew Hume



Re: Continued RFC process

2000-10-10 Thread Jonathan Scott Duff

On Tue, Oct 10, 2000 at 03:11:54pm -0500, David Grove wrote:
 They think I'm paranoid and the only one who sees the danger.
 Relatively few people speak openly about it for fear of getting the
 same beatings I get on a regular basis.  Frankly I think it's
 important for these guys just to realize that other people are sitting
 back and watching, with unexpressed interests.

Perhaps it's just me, but I don't see a problem yet.  If Perl were
somehow being "taken over", then I expect the Perl community (at the
very least, one David Grove :-) to be up in arms about it.  

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]



RE: Continued RFC process

2000-10-10 Thread David Grove

On Tuesday, October 10, 2000 1:33 PM, Jonathan Scott Duff 
[SMTP:[EMAIL PROTECTED]] wrote:
 David Grove wrote:
  Read-only and carefully censored lists are irrelevant to the goals of
  Perl 6's giving voice to the perl community.  They lead us right back
  where we were before, with a core group free to sit back unchallenged
  on their complacency and let Perl go to rot.

 What does "unchallenged on their complacency" mean?  In the world of
 OSS, those that have time and inclination design or code things they
 find interesting.  If no one champions a cause, nothing happens.  It
 sounds like you are saying that if the community wants Feature X and no
 one steps up to write the code to add Feature X to perl, then "the
 community" should somehow be able to force the developers that are
 already working on some aspect of perl to add Feature X.

  However, I don't agree that the developers should be able to ignore
  the community within a closed-off little clique.

 What community needs do you feel are being ignored?

"Unchallenged on their complacency": knowing the issue and ignoring it because 
it doesn't affect them or their O/S, or in Tom's case, his personal 
workstation. Having a sudden shock of amazement, anger, and comprehension that 
the problem exists, then forgetting about it because they don't have to care.

To those who don't know the old argument, which out of respect for the list and 
the listmaster I won't detail, I'm not talking about features so much as 
corporate collusion and corporate control. In the Win32 world, this has been 
very real, and very painful, but the P5P mostly ignored the issues because they 
were either not interested in Win32 affairs, or affected in other ways. The 
community need that I _know_ is being ignored is the ability to have a perl 
that's not taking a dive toward being slopped all over with the four-colored 
flag. Community interest must take a higher precedence in the development of 
Perl 6 than corporate interests, if Perl 6 is to be a "community project" at 
all.

To those who do know the old argument and still think I'm paranoid, just see 
the logic in being _able_ to control the problem, since it is definitely at 
least a potential.

To those who do know the old argument and don't think I'm paranoid, please 
speak up. Don't just private mail me.

I _choose_ not to be paying for perl by 2005.





Re: Continued RFC process

2000-10-10 Thread Simon Cozens

On Tue, Oct 10, 2000 at 03:38:17PM -0500, Jonathan Scott Duff wrote:
 Perhaps it's just me, but I don't see a problem yet.  If Perl were
 somehow being "taken over", then I expect the Perl community (at the
 very least, one David Grove :-) to be up in arms about it.  

And then they could fork, and Perl would stay free. Crisis over.

IT'S OPEN SOURCE.

David, go understand what that means.

-- 
IBM:
It may be slow, but it's hard to use.



David's paranoia again (was Re: Continued RFC process)

2000-10-10 Thread Randal L. Schwartz

 "David" == David Grove [EMAIL PROTECTED] writes:

David The community need that I _know_ is being ignored is the
David ability to have a perl that's not taking a dive toward being
David slopped all over with the four-colored flag. Community interest
David must take a higher precedence in the development of Perl 6 than
David corporate interests, if Perl 6 is to be a "community project"
David at all.

Your rantings are based on unverified claims, once again.

In case someone comes into the middle of this conversation, please
read the past threads that reveal at every turn just how disconnected
David is from reality on this point.

David To those who do know the old argument and still think I'm
David paranoid, just see the logic in being _able_ to control the
David problem, since it is definitely at least a potential.

David - some of being part of a community means that YOU won't have
control.  I think you keep forgetting that.

There is one person to whom you will have to defer your control
ultimately, and that's Larry Wall.  Larry will do what he does with
Perl.  If you don't like it, the door is over there.  Get used to
that.

Larry approved Sarathy's release of 5.6, including the timing and the
content.  Stop using that as an example of some evil corporate greed.

Larry is probably one of the truest
can't-be-influenced-by-corporate-greed people I know.  You disrespect
him when you suggest the process is being undermined.

David I _choose_ not to be paying for perl by 2005.

And Larry will ensure that.  If you can't trust him to do that, please
stop using Perl now, to cut your losses.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!



RE: Continued RFC process

2000-10-10 Thread Dan Sugalski

At 02:11 PM 10/10/00 -0500, David Grove wrote:
However what I was responding to was the shutting out of anyone who 
doesn't agree with the politics of the perl elite, and wants to mouth off 
from time to time (me). You sort of have to read between the lines on this 
one, Peter, because this is an old argument. Nobody's actually saying what 
they mean, and I think we prefer it that way.

We don't prefer it that way, honestly. This dancing around the issue is 
damned annoying. Let's be blunt here.

Your two big beefs seem to be that WinXX gets shorted in the development 
process, and that ActiveState is doing Evil Things. (That ActiveState has 
been responsible for 90% of the WinXX code in perl seems to not have made a 
difference, but we shan't go there right now)

I don't much care about the latter problem--Larry feels he's resolved it 
and I'm fine with that. This is, as far as I'm concerned, his baby.

As for the former Y'know what? That's probably not going to change. 
Perl lives and grows based entirely on contributions of source from the 
world. I don't have a Windows development system, I'm not at all familiar 
with developing on Windows, and I'm not *going* to develop on Windows. 
Period. You want Windows support? Great. Write the code and send it in. 
Don't like the install system? Go build one you do.

I, for one, won't refuse code from anyone for personal reasons--if the 
code's solid (or there's no alternative) I'll take it no matter how much I 
might dislike someone. (Though it never helps to come across as a paranoid 
nutcase) I'll reject it on technical grounds, of course, but that's a 
separate matter.

The problem with this is the assumption. There is _no_ assumption possible 
that the developers will read a free list, or care what it says.

You're being too specific. There is no assumption possible that perl 
developers will do *anything*. Ever. This is a volunteer community. Any 
other assumption you might make is unfounded. There is no central 
authority. There is no guaranteed management control. There is no 
*nothing*. Perl is an open source project whose development is currently 
run by a group of interested parties. Don't like the way it's run? Fork the 
source and go for it.

Dan, I don't know you. I've never had any problem with you or your leadership.

That's fine. I fully expect that someone (and this is a generic someone 
here--I have no names in mind) will by the time this is all done. I'm not 
at all thrilled at the prospect, but it's one of the first things I came to 
terms with after volunteering.

I don't believe that you'll head us into a mess, because I've no reason to
believe it. You are also not technopolitically inclined in the same direction
as your predecessor.

I should point out two things:

1) Sarathy isn't technopolitically inclined in the way you think
2) My technopolitical leanings are likely not to your (or some other 
people's) tastes

I have no arguments with you. However, the possibility
still exists, and always will, unless some kind of check/balance system is in
place.

What you want isn't currently possible. Period. The only way to make it 
even remotely possible is to entrust perl development to some sort of 
entity akin to the Apache Software Foundation, and if we do that we will 
undoubtedly piss of yet another group of people. (And you'll likely be in 
that group too)


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk




Re: Continued RFC process

2000-10-10 Thread Simon Cozens

On Tue, Oct 10, 2000 at 05:40:04PM -0400, Dan Sugalski wrote:
 You're being too specific. There is no assumption possible that perl 
 developers will do *anything*. Ever. This is a volunteer community. Any 
 other assumption you might make is unfounded.

David also seems to miss the irony that the people who *can* be expected to
work on Perl because they being paid to do so are probably employed by...

Anyway, this is generating light. Could someone start generating heat, please?

-- 
Anything to do with HTML processing /usually/ involves a pact
with an evil supernatural being, I find.
-- Sean Burke



Re: Continued RFC process

2000-10-10 Thread Dan Sugalski

At 10:48 PM 10/10/00 +0100, Simon Cozens wrote:
On Tue, Oct 10, 2000 at 05:40:04PM -0400, Dan Sugalski wrote:
  You're being too specific. There is no assumption possible that perl
  developers will do *anything*. Ever. This is a volunteer community. Any
  other assumption you might make is unfounded.

David also seems to miss the irony that the people who *can* be expected to
work on Perl because they being paid to do so are probably employed by...

I know, I know! Compaq, right? :)

Anyway, this is generating light. Could someone start generating heat, please?

Sure. This does bring up one important point, though it's getting lost in 
everyone jumping on Dave for being a paranoid loony.

Under what circumstances, and with what procedures, do we 'officially' 
remove folks from their positions? I know that I, for one, will step down 
if either Nat or Larry asks, but what happens if for some reason I turn 
into a raving nutter and won't go? Or if someone just disappears and we 
need a new person in the position?

"General consensus" is best, but that can't be guaranteed. "Consensus of 
the ruling council" is more attainable, but there's that whole "ruling 
council" thing to contend with. "What Larry says" is best, but what happens 
if he doesn't, or gets hit by a bus at some point?

It's not a pleasant thing to deal with, and hopefully not ever needed, but 
it's better to deal with now when we don't have to than later when we do...

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk




Re: Continued RFC process

2000-10-10 Thread Simon Cozens

On Tue, Oct 10, 2000 at 06:01:16PM -0400, Dan Sugalski wrote:
 "General consensus" is best, but that can't be guaranteed. "Consensus of 
 the ruling council" is more attainable, but there's that whole "ruling 
 council" thing to contend with. "What Larry says" is best, but what happens 
 if he doesn't, or gets hit by a bus at some point?

I'd be happy with "what the project manager says". We trust the project
manager to be able to gauge "general consensus" and decide what's best for
Perl. It gives us a "what Larry says" style polity without the sacred cow.

And if the project manager goes mad (in the case of Nat, more mad :) and we 
have to shoot him, then Larry should do that. And if Larry gets bussed, look
around at other open source projects and see what happens when the
maintainer's unmaintainable - people either stick it out, or fork.

-- 
Grr... don't get me started on Wagner.  The man couldn't resolve a
dominant seventh to a tonic with two musical dictionaries open to the
word "resolution", and a copy of anything by Muddy Waters.
- Eric the Read, in the monastery.



Re: Continued RFC process

2000-10-10 Thread Dan Sugalski

At 11:12 PM 10/10/00 +0100, Simon Cozens wrote:
On Tue, Oct 10, 2000 at 06:01:16PM -0400, Dan Sugalski wrote:
  "General consensus" is best, but that can't be guaranteed. "Consensus of
  the ruling council" is more attainable, but there's that whole "ruling
  council" thing to contend with. "What Larry says" is best, but what 
 happens
  if he doesn't, or gets hit by a bus at some point?

I'd be happy with "what the project manager says". We trust the project
manager to be able to gauge "general consensus" and decide what's best for
Perl. It gives us a "what Larry says" style polity without the sacred cow.

And if the project manager goes mad (in the case of Nat, more mad :) and we
have to shoot him, then Larry should do that. And if Larry gets bussed, look
around at other open source projects and see what happens when the
maintainer's unmaintainable - people either stick it out, or fork.

And that all works for me. Anyone care to RFC it? :)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk




RE: Continued RFC process

2000-10-10 Thread David Grove

On Tuesday, October 10, 2000 3:27 PM, Simon Cozens [SMTP:[EMAIL PROTECTED]] 
wrote:
 Consider:
 "Public Opinion": Hey, we need Perl 6 stable in three weeks.
 Coders: But, uhm, we haven't started coding yet.

Consider:
   Microsoft: We need Perl by April 15th
   Head Cheese: Ok, sure
   P5P: HuH???
   "Public Opinion": HuH???
   [Result: Perl 5.6 chaos]

Consider:
   Microsoft: We need Perl by April 15th
   Head Cheese: Ok, sure
   P5P: HuH???
   "Public Opinion": Bite me
   [Result: theoretical stable release at a proper time]

Get real.

No, offense, Dan. This isn't targeting you. I think you're starting to realize 
this now. At first, I think you thought I was.




Re: Continued RFC process

2000-10-10 Thread Russ Allbery

Dan Sugalski [EMAIL PROTECTED] writes:
 At 09:31 AM 10/10/00 -0600, John Barnette wrote:

 D'you think it's a possibility to provide read-only access to the lists
 for interested parties?  I'm certainly not competent enough to
 contribute to a core discussion, for example, but I have no doubt that
 my eventual Perl6 facility would be greatly increased by observing the
 dialogue.

 Read-only access is a must for any list like this, and with more than
 just a web archive. I'm sure Ask will set things up so anyone that likes
 can subscribe to the read-only version of the list.

Ask and I have both been incredibly busy, but I believe it's even still
the intention to make the traffic of the mailing lists available as
newsgroups as well (with posts receiving an autoresponse explaining the
nature of the mailing list and how to go about participating if the person
really wants to).

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/



Re: Continued RFC process

2000-10-10 Thread Russ Allbery

Dave Storrs [EMAIL PROTECTED] writes:

 Is anyone here familiar with the behind-the-scenes process and politics
 of the Linux development community?

Not heavily familiar, but I know some details.  (My knowledge is that of
someone who's been following linux-kernel sporadically for a year or two
and reads the Kernel Traffic summaries fairly religiously, as well as pays
attention to Alan's diary and various other natterings on the topic
whenever they come up, as I have a strong interest in open source project
management.)

 If I understand it correctly (and I'm not sure I have the details
 right), when Linux was being developed, Linus came up with a skeletal OS
 based off of MINIX, then he turned it loose.  People volunteered bits of
 code which Linus integrated into the OS.  As the thing snowballed, Linus
 couldn't handle the volume, so he chose a group of lieutenants who also
 had commit authority.

Not quite on the last part.

Linux has no version control, believe it or not.  (Well, various people
are tacking version control systems on the side, but as I understand it
Linus himself doesn't use version control and all of those other trees are
either for subprojects or after-the-fact imports.)  So there isn't such a
thing as "commit authority," quite.

What Linus seems to do more of is just ignore patches unless they come
from the right people or strike him right, and in particular if someone is
listed as the maintainer of a piece of code in the appropriate file, Linus
expects people to send patches for that code to that maintainer and wants
to incorporate patches from that maintainer.  But all patches get reviewed
by him, and even Alan Cox gets patches bounced by Linus on a pretty
regular basis.

 Now, I'm not sure where the planning came from...was there a specific
 website or elist or whatever where Linus said "ok, we'd like a TCP/IP
 stack that has the following interface?"  Or what?

What I've seen on linux-kernel is that getting new ideas isn't the trouble
at all.  *Rejecting* new ideas is most of what Linus has to do.  The times
when he sets policy on something like that have all been on linux-kernel
that I've seen.

I would be a bit reluctant to adopt Linux's general development model,
since quite a lot of it as it currently works rests on the fact that Linus
is superhuman.  He can maintain quality code without version control, he
can debug kernels without a kernel debugger, he can manage patch
submissions without a bug database, and he can keep track of what he's
doing without a change log.  It works for him, so more power to him, but
that really is powers and abilities far beyond those of mortal man, and I
don't think we can expect the Perl maintainers to have similar god-like
powers.

 Whatever they did worked, and I haven't heard anything to suggest that
 the Linux community feels excluded...

You've missed a *whole* bunch of political arguments, I'm afraid.  It's a
standing conspiracy theory that Linux development is being dominated by
Red Hat to the exclusion of other distributions, etc. etc.  Very similar
to some of the ActiveState conspiracy theories that I've heard, actually;
in fact, in some of them, you could do s/Alan Cox/Sarathy/ and get
basically the same rant, complete with the assurances that they consider
the actual tool of the Great Enemy to be a wonderful person.

I think this is par for the course in large, high-profile open source
software projects, regrettably.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/



Re: Continued RFC process

2000-10-10 Thread J. David Blackstone

 
 
 On Mon, 9 Oct 2000, Nathan Torkington wrote:
 
 Closed-for-posting mailing lists that are publically readable is the
 best suggestion we've had to meet these ends so far.

 Anyone have better suggestions?

  I don't know that this is _better_, but...perhaps we could have
 the lists that you suggest, but also have separate, publicly postable,
 lists where anyone could comment.  If one person from the design committee
 would be willing to read these public lists and interact with the people
 there, saying "that's a good idea, we'll use it" or (probably more common)
 "we'd like to do that, but we can't for reasons XYZ," that would go a long
 way towards making the community feel invovled.  Perhaps this duty could
 rotate, so that various design-committee voices would be heard on the
 outside.

 Dave



  I think this is what most people have had in mind all along: a
read-only list for those trusted to be responsible for each portion of
the project, coupled with an open list where anyone can have input.
I'm talking a pair of lists for each working
group/committee/whatever-you-want-to-call it.

jdb



Re: Continued RFC process

2000-10-10 Thread Dan Sugalski

At 07:09 PM 10/10/00 -0600, Nathan Torkington wrote:
Dan Sugalski writes:
  "General consensus" is best, but that can't be guaranteed. "Consensus of
  the ruling council" is more attainable, but there's that whole "ruling
  council" thing to contend with. "What Larry says" is best, but what 
 happens
  if he doesn't, or gets hit by a bus at some point?

In terms of ongoing maintenance, I'd say that the teams will act as
the Ruling Council.  When teams get pissed off with the release
manager, then the leader will have to go.  When members of a team
can't work together, then the release manager works with them to
figure out where the problem is and fix it.  This might be everything
from "play nice" to hiring a hitman :-)

Works. We still have those Quantum Ninja that we're holding in reserve for 
Damian... :)


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk




RE: Continued RFC process

2000-10-10 Thread Dan Sugalski

At 05:59 PM 10/10/00 -0500, David Grove wrote:
On Tuesday, October 10, 2000 3:27 PM, Simon Cozens [SMTP:[EMAIL PROTECTED]]
wrote:
  Consider:
  "Public Opinion": Hey, we need Perl 6 stable in three weeks.
  Coders: But, uhm, we haven't started coding yet.

Consider:
Microsoft: We need Perl by April 15th
Head Cheese: Ok, sure
P5P: HuH???
"Public Opinion": HuH???
[Result: Perl 5.6 chaos]

No, M$ didn't have much to do with it. You can yell at Larry and Camel 
deadlines if you like, but that's wrong too.

5.6 was released because it was mostly done, more stable than 5.005 for the 
bits it had in common, and because of general apathy in the developer realm 
for the bits that were unfinished. Like, for example, Unicode.

No, offense, Dan. This isn't targeting you. I think you're starting to 
realize  this now. At first, I think you thought I was.

No, I never thought you were. Or, more specifically, I never really gave it 
much thought and didn't care if you were or not. You mistook courtesy, lack 
of time, and a desire to not appear domineering for offense.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk




Re: Continued RFC process

2000-10-10 Thread Dan Sugalski

At 04:51 PM 10/10/00 -0700, Daniel Chetlin wrote:
On Tue, Oct 10, 2000 at 08:23:07PM +0100, Nicholas Clark wrote:
  Having had cause to root around in the archives of perl6 and perl5 lists,
  can I suggest that we use the system that perl5-porters is archived on in
  preference to the system that the perl6 lists use (MHonArc, apparently).
  Personally I found the threaded summaries and search facility on the perl5
  archive much more effective. What do other people think?

Er, compared to what the perl6 lists are doing right now anything is
preferable. But xray _sucks_! Given the choice between searching xray
and chewing tinfoil, I might choose the tinfoil.

I'm trying to get them on a regular crawl schedule at work (I work for 
Northern Light, one of the search engines) but that's a spotty thing at the 
moment. (Soon, though, I hope... :)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk




RE: Continued RFC process

2000-10-10 Thread Dan Sugalski

At 09:04 PM 10/10/00 -0400, Bryan C. Warnock wrote:
  On Mon, 9 Oct 2000, Nathan Torkington wrote:
 
   Closed-for-posting mailing lists that are publically readable is the
   best suggestion we've had to meet these ends so far.
  
   Anyone have better suggestions?
 

Instead of group-writable and world-readable, how about group-writable
and world-moderated?

(Or just plain moderated, with the flavor o' the day being
autohandled...)

It's more work, which I am not a fan of, but I'm not a fan of everybody
having a say, nor a select few workers having a say.

I rather like it. Russ did have a point earlier, and I'm tempted to leave 
things open at the moment, or go the dual-subscription route and 
automoderate everything as OK until a problem arises.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk




Re: Continued RFC process

2000-10-10 Thread Nathan Wiger

Dan Sugalski wrote:
 
 Works. We still have those Quantum Ninja that we're holding in reserve for
 Damian... :)

Yeah... they're vicious, too - they kick ass in constant time. ;-)

-Nate



Re: Continued RFC process

2000-10-10 Thread J. David Blackstone

David Grove wrote:
 The 
 community need that I _know_ is being ignored is the ability to have a perl
 that's not taking a dive toward being slopped all over with the four-colored
 flag.

  David, please, you must be more specific and less idiomatic.  I
don't even know what the four-colored flag is.  I keep thinking I
understand you, but I keep hearing you say you're not repeating
everything because it's an old argument.  Every time you get pressed
to say more, you use this expression I don't understand.

 To those who don't know the old argument, which out of respect for the list
 and
 the listmaster I won't detail, I'm not talking about features so much as
 corporate collusion and corporate control.

  Could you please at least provide links to a few key messages on the
p5p archives?  You keep saying that others agree with what you're
saying but are silent or have left.  Please: where are their messages?

  Why can't you fork your own development process, if it means this
much to you and others?  Won't they join you?

jdb



Re: Continued RFC process

2000-10-10 Thread J. David Blackstone

 On Tue, Oct 10, 2000 at 06:01:16PM -0400, Dan Sugalski wrote:
 "General consensus" is best, but that can't be guaranteed. "Consensus of
 the ruling council" is more attainable, but there's that whole "ruling
 council" thing to contend with. "What Larry says" is best, but what
 happens
 if he doesn't, or gets hit by a bus at some point?

 I'd be happy with "what the project manager says". We trust the project
 manager to be able to gauge "general consensus" and decide what's best for
 Perl. It gives us a "what Larry says" style polity without the sacred cow.

 And if the project manager goes mad (in the case of Nat, more mad :) and we
 have to shoot him, then Larry should do that. And if Larry gets bussed, look
 around at other open source projects and see what happens when the
 maintainer's unmaintainable - people either stick it out, or fork.

  I think open source has all this built in.  If you go nuts, Dan,
someone with authority pulls your commit access.  If I think you're
not nuts, then you and I go off and fork our own perl (you get to do
most of the work).  The better development effort wins.

  I repeat my suggestion from a couple of days ago that someone author
a document on "how to politely fork your own development effort,"
something akin to the discussion on the subject from Karl Fogel's
_Open Source Development With CVS_, but tailored to the Perl scene.
It should be entirely possible for a person to politely start his own
development on a P*rl-compatible interpreter (or even a spec) and
invite developers to participate on his project without abandoning the
real one.  (In reality, I think we all know it's usually a little
different, but it's possible in theory, at least.)  Such a document,
while hopefully never needed, would help remind everyone that Perl
really does depend on the will of the community (and always has and
always will).

jdb



Re: Continued RFC process

2000-10-09 Thread Dan Sugalski

At 06:38 PM 10/8/00 -0400, Uri Guttman wrote:
the second part is internals. not to take anything from dan, but i see a
bottom up approach being very useful here.

I disagree. This is too big a project to manage that way. If we do it we're 
setting ourselves up for an enormous amount of trouble later on. (And not 
that much later at that) The various pieces *must* have well-defined 
interfaces and behaviours, and that absolutely has to be specified before 
work begins on any particular piece.

hammer out some
working/prototype vtable code, work on the new I/O subsystems (this is a
big project in its own right), work on byte code and related design
issues, etc. again, these teams should be led and staffed by people with
real experience in those areas. this should not be a public exercise
(again read only should apply to any outsiders).

Sure, as long as the behaviours of the individual pieces are known when 
work starts.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk




Re: Continued RFC process

2000-10-09 Thread Uri Guttman

 "DS" == Dan Sugalski [EMAIL PROTECTED] writes:

  DS At 06:38 PM 10/8/00 -0400, Uri Guttman wrote:
   the second part is internals. not to take anything from dan, but i see a
   bottom up approach being very useful here.

  DS I disagree. This is too big a project to manage that way. If we do
  DS it we're setting ourselves up for an enormous amount of trouble
  DS later on. (And not that much later at that) The various pieces
  DS *must* have well-defined interfaces and behaviours, and that
  DS absolutely has to be specified before work begins on any
  DS particular piece.

well, i don't think we are really disagreeing. i was musing on this
stuff and i have found some bottom up hacking to be useful. not the
whole project, but certain well defined low level systems can be done
that way. notice i also said well defined (i should have said it in my
previous letter). my point is that you don't have to specify the entire
system before you can spec and develop some tightly wrapped parts. or
consider this work on proof of concept or prototyping. for example, you
and i both want full support of native async I/O. we also agree it has
to be intgrated with an event loop. we can prototype such an event loop
based on several versions we have access to and integrate async file i/o
into them. this would be a well defined low level subsystem below
stdio. in fact it could be so general as to not even have anything about
perl in it. this even goes back to simon's push for using glibc (i think
that was the library he was pushing).

  DS Sure, as long as the behaviours of the individual pieces are known when 
  DS work starts.

well, we do know event loops and async i/o very well and could define
such a subsystem right now. i am not saying do that but it is an example
of how we can leverage our work force in parallel while the top down
spec work is going on.

again, i don't think we are disagreeing, just communicating.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com



RE: Continued RFC process

2000-10-09 Thread David Grove

On Monday, October 09, 2000 1:17 AM, Dan Sugalski [SMTP:[EMAIL PROTECTED]] wrote:
 At 04:13 PM 10/8/00 -0600, Nathan Torkington wrote:
 I've heard people asking for RFCs to continue after the brainstorming.
 What do we want to do that we need RFCs for?  Design?  Implementation?
 Working out the fine details of behaviour?

 What I'd like to see is the internals design and implementation use RFCs as
 the specifications and documentation for the different pieces of the guts.
 I'm not sure the free-for-all way we handled things to start is appropriate
 (I'm rather sure it's *not*), but that's OK, since the requirements are
 different.

 Much as folks might dislike it, I think some sort of prefilter is in order
 for RFCs if we continue that way. (We'll be doing *something* of the sort
 on the internals side) RFCs should have at least some solidity before they
 hit the standards track. Feasable would be nice, but if someone wants to
 present an alternative to the current implementation of something (vtables,
 variables, interpreter structure) that's fine--we may need a Plan B at some
 point. Or Plan C, since I suppose we're working on Plan B now.

 The separate sub-lists are definitely a useful tool in some circumstances,
 and I'd like to see those used as well. The internals encompasses a lot of
 area, and having separate lists should make life an awful lot easier.
 (Whether this ultimately proves to be true is a separate issue) The folks
 designing the bytecode don't, for example, need to interact a whole lot
 with the folks designing the garbage collection code.

 All this might just be an internals-only issue, and if that's the case then
 I'm fine with that. If it's not, though, it seems to make sense to
 coordinate things project-wide.

All else aside, I feel that it is important to keep Perl6 open to the public in 
all respects and in all phases. I realize that's hard to do, and "core" 
developers get swamped, but without a public voice we risk falling back into 
the same problems caused by the current elitist mentality. How can we give the 
core developers some peace while still giving users direct voice? Or, fully 
realizing that Perl development is completely voluntary making election 
impossible, perhaps there should at least be some kind of "checks and balances" 
in place, or a public appeal or impeachment process.

I really don't want to see another Camel where every other page has a "this 
isn't quite finished" phrase of some kind just because... well, for whatever 
reason.

Closing out the public sounds like what this is about, and that's very 
Perl5ish, and, from what I understand of it, totally contrary to the expressed 
goals of Perl6. Everybody needs a soapbox, and creating a closed-off elitist 
regime is not an effective way of giving the public a direct say in the 
development of Perl6. If the "public say" is limited to an RFC freeforall, then 
closed off to let the elite go to work, then the whole "public say" policy is a 
farce an order of magnitude worse than the "great perl merge". Either the 
public has a voice, or it doesn't.





Re: Continued RFC process

2000-10-09 Thread Jonathan Scott Duff

On Mon, Oct 09, 2000 at 11:09:08AM -0500, David Grove wrote:
 All else aside, I feel that it is important to keep Perl6 open to the
 public in all respects and in all phases. 

You're right, which is why Perl 6 *is* open to the public.  Anyone can
contribute their ideas or code.  But someone has to make the judgement
call about what's put in the stew pot and what's not.  That decision
making process most empatically should *not* include everyone under
the sun.

 I realize that's hard to do,
 and "core" developers get swamped, but without a public voice we risk
 falling back into the same problems caused by the current elitist
 mentality. 

What problems are you referring to?  For that matter, what elitist
mentality are you referring to?

 How can we give the core developers some peace while still
 giving users direct voice? Or, fully realizing that Perl development
 is completely voluntary making election impossible, perhaps there
 should at least be some kind of "checks and balances" in place, or a
 public appeal or impeachment process.

So ... if a large portion of "users" dislike the direction that the
internals design and implementation is going, they can impeach Dan?

I don't understand what problem you are trying to solve.

 I really don't want to see another Camel where every other page has a
 "this isn't quite finished" phrase of some kind just because... well,
 for whatever reason.

I wouldn't want to see that either.

 Closing out the public sounds like what this is about, and that's very
 Perl5ish, and, from what I understand of it, totally contrary to the
 expressed goals of Perl6. 

Indeed, closing people out sounds completely contrary to the perl 6
development process.

 Everybody needs a soapbox, and creating a closed-off elitist regime is
 not an effective way of giving the public a direct say in the
 development of Perl6.

Yep, that's not an effective way to do it.

 If the "public say" is limited to an RFC freeforall, then closed
 off to let the elite go to work, then the whole "public say" policy
 is a farce

Well, that makes no sense.  Either you trust your developers or you
don't.   Everyone says their mind and then it's up to the developers
to take into account all of the myriad requests and decide if they
should become part of the project and if so, how.  Everyone
participating in that decision making process is a recipe for
disaster.

How would you do it?  

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]



Re: Continued RFC process

2000-10-09 Thread Simon Cozens

On Mon, Oct 09, 2000 at 11:09:08AM -0500, David Grove wrote:
 I realize that's hard to do, and "core" developers get swamped, but
 without a public voice

   Perl 6 Public Relations - brian d foy
  The public relations side of development relays important
  events and happenings from the development side of Perl to the
  general public, including the press and Perl community.

It's not a problem, David.

-- 
We use Linux for all our mission-critical applications. Having the source code
means that we are not held hostage by anyone's support department.
(Russell Nelson, President of Crynwr Software)



Re: Continued RFC process

2000-10-09 Thread Simon Cozens

On Mon, Oct 09, 2000 at 01:10:57PM -0500, David Grove wrote:
 Perl 6 Public Relations - brian d foy
 
 Public relations? Uh, who is the Perl 6 information officer?

I don't have the faintest idea.

-- 
"You can have my Unix system when you pry it from my cold, dead fingers."



Re: Continued RFC process

2000-10-09 Thread Stephen Zander

 "David" == David Grove [EMAIL PROTECTED] writes:
David If the "public say" is limited to an RFC freeforall, then
David closed off to let the elite go to work, then the whole
David "public say" policy is a farce an order of magnitude worse
David than the "great perl merge". Either the public has a voice,
David or it doesn't.

Sorry, I disagree.  If I'm building a house I don't sit there and
critique the way the carpenter hammers nails.  I do, however, make
sure the architect and I understand what the finished building will
look like.

The lack of difference between perl and Perl has been the greatest
cause of unease, disquiet and the disenfranchisement of parts of the
Perl community because it's impossible to talk about one without
involving the other.  Clearer seperation of language and
implementation with clear specifications and a public process for the
former is sufficient for this to be avoided for Perl6.  It is not
necessary to allow everyone the ability to comment on every phase *as
it happens*.

-- 
Stephen

"Good idea, O Lord!"... "'Course it's a good idea!"



RE: Continued RFC process

2000-10-09 Thread David Grove

On Monday, October 09, 2000 3:22 PM, Stephen Zander [SMTP:[EMAIL PROTECTED]] 
wrote:
 The lack of difference between perl and Perl has been the greatest
 cause of unease, disquiet and the disenfranchisement of parts of the
 Perl community because it's impossible to talk about one without
 involving the other.  Clearer seperation of language and
 implementation with clear specifications and a public process for the
 former is sufficient for this to be avoided for Perl6.  It is not
 necessary to allow everyone the ability to comment on every phase *as
 it happens*.

Understood. I'm just hoping for a mechanism to be in place that will prevent 
the _fourth_ version of camel from being as incomplete as the third. It's hard 
to teach new programmers out of a book that backpaddles on every third feature. 
(Yes, that's an exaggeration.) The only thing I can realistically think of is 
some sort of check and balance system. I don't think it's a good idea for 
everybody to step on core developers' toes, but the perl community needs to be 
able to direct or _help_ direct, or guide, the process as a whole. I'm seeing 
messages to the effect of, "Ok, they've had their say, now let's make 
everything private again and go to work." No, No, No.

There has to be some kind of middle ground we can find, no?





RE: Continued RFC process

2000-10-09 Thread Nathan Torkington

David Grove writes:
 There has to be some kind of middle ground we can find, no?

Nobody's suggesting complete quiet.

What we're seeing is the fundamental conflict of:
 - the need for a coherent design meaning that very few people control
   the design
 - the need for openness and public involvement to avoid misdirection
   or malfeasance

Closed-for-posting mailing lists that are publically readable is the
best suggestion we've had to meet these ends so far.

Anyone have better suggestions?

Nat



RE: Continued RFC process

2000-10-09 Thread David Grove

On Monday, October 09, 2000 7:12 PM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] 
wrote:
 David Grove writes:
  There has to be some kind of middle ground we can find, no?

 Nobody's suggesting complete quiet.

 What we're seeing is the fundamental conflict of:
  - the need for a coherent design meaning that very few people control
the design
  - the need for openness and public involvement to avoid misdirection
or malfeasance

 Closed-for-posting mailing lists that are publically readable is the
 best suggestion we've had to meet these ends so far.

 Anyone have better suggestions?

 Nat

How about an open, crossplatform mailing list for issues, with a mechanism on 
perl.org for public voting on larger issues. The issue would be given, 30 days 
would take the polls, it would be as rig-proof as possible, and Larry would 
have the power to veto (final say period). That gives a soapbox, guidelines 
(Win32 and Mac are people too - elitists well we'll see), a direct public 
effect on Perl, and Larry's final say over his intellectual property. Simple 
majority rule on issues, 2/3 to impeach, simple majority per O/S to release. 
Takes n requests to come to a vote (keep it low until we know what we're 
working with), fully automated (pre-poll or signature style). Authenticated 
emails only (a la majordomo), real emails only (sorry hotmail). I'd be happy to 
help with setting it up if needed (polling system).

Good? Bad?

It's simple enough to achieve the objectives, I think.



Re: Continued RFC process

2000-10-09 Thread J. David Blackstone

  This proposal has some good thoughts.  Cut me some slack for not 
being completely supportive of it; in my country, when they allowed
the public to ask the elite candidates for office any question they
wanted, the favorite question was "Do you wear boxers or briefs?"

 How about an open, crossplatform mailing list for issues, with a mechanism
 on
 perl.org for public voting on larger issues. The issue would be given, 30
 days
 would take the polls, it would be as rig-proof as possible, and Larry would
 have the power to veto (final say period). That gives a soapbox, guidelines
 (Win32 and Mac are people too - elitists well we'll see),

  Speaking as a Mac user, I don't know that we particularly feel left
out or anything.  Then again, I'm also a UNIX user, and being both is
not the norm (at least, not until OS X catches on).

 a direct public
 effect on Perl, and Larry's final say over his intellectual property. Simple
 majority rule on issues, 2/3 to impeach,

  Do you mean impeach a person (Larry? or someone else?), or do you
mean override a veto?

 simple majority per O/S to release.

  That could be tricky, since the number of Perl users per OS is very
disproportionate.  When they drafted the U.S. constitution, there was
a huge debate over whether to base congressional representation on
population per state or make each state equal.  Both sides had a good
claim to the other being unfair; giving a smaller state (Rhode Island,
or Mac users) equal say with a larger one can seem unfair to the
larger segment, and I think in this case it would be.  ("No,
seriously, guys, I think we should move the epoch to 1904.")

 Takes n requests to come to a vote (keep it low until we know what we're
 working with), fully automated (pre-poll or signature style). Authenticated
 emails only (a la majordomo), real emails only (sorry hotmail).

  This is real tricky; nearly everyone reading what I'm saying is
fully capable of writing a program to register 1000 hotmail addresses
and vote 1000 times, but this doesn't mean that all hotmail addresses
are fake (though I would presume that nearly anyone capable of
participating in this process has a real email account).  Plus, the
fact that an email is from a more legitimate domain doesn't
necessarily mean that it represents a unique person; plenty of ISPs
give multiple mail accounts.  Is aol.com a domain of real email
addresses?  (What about wall.org? ducks for cover/)

 Good? Bad?

 It's simple enough to achieve the objectives, I think.

  If enough people really feel that worried about Perl falling into
the hands of a few, then something like this might be a good idea.  I
feel protected against such emergencies by the possibility of forking.
I realize I just broke through into a place none of us wants to go.
(Let me reiterate very carefully: *none* of us wants to go there,
least of all, me.)  However, if Microsoft or whoever were to somehow
to gain total control of Perl, couldn't somebody just go off and
create a Perl-compatible p*rl, according to the GPL and/or Artistic
License?  And if not, why not?  Perhaps there should even be an
officially blessed, "How to politely fork Perl development and choose
a new name if you're really that unhappy and think there's enough
people who think like you to join you" document.

  The possibility of such a fork keeps me from worrying about most of
the issues you raise.  However, if everyone's really that worried,
then formal mechanisms would be in order.

  Let me make the following proposal: let's test your idea on itself.
Require n nominations/seconds/whatever to bring your idea to a vote (n
should be determined by you and Nat Torkington).  If it does come to a
vote, conduct it in 30 days, along the lines you have said, and if it
passes with a simple majority, give it to Larry as a proposal and see
if he wants to veto it.  I'll go on the record as saying I would vote
against the proposal, but wouldn't be upset if it passed.

jdb



Re: Continued RFC process

2000-10-09 Thread John Porter

J. David Blackstone wrote:
 
 When they drafted the U.S. constitution, there was
 a huge debate over whether to base congressional representation on
 population per state or make each state equal.  Both sides had a good
 claim to the other being unfair; giving a smaller state (Rhode Island,
 or Mac users) equal say with a larger one can seem unfair to the
 larger segment, and I think in this case it would be.  ("No,
 seriously, guys, I think we should move the epoch to 1904.")

I agree with jdb.  One equivalent vote per person opens the possibility
that some company in Redmond could assign 250 of its employees to
"go vote in that Perl thing and make it ours".
In fact, I'd be uncomfortable thinking that my vote counted as much as,
say, Ilya's.

Also, I'd point out a weakness in the presidential analogy for Larry.
The President of the U.S. can only veto; any legislation he ignores
passes by default.  Also, the President cannot introduce legislation.
Rather, Larry is like a king; and we are his ministers, courtiers, and
noblemen.  We can argue til we're blue, debate, resolve, and vote; but
in the end, it's Larry who makes the decision.

-- 
John Porter

By pressing down a special key  It plays a little melody




Re: Continued RFC process

2000-10-09 Thread Dan Sugalski

At 10:36 PM 10/9/00 -0500, J. David Blackstone wrote:
  J. David Blackstone wrote:
 
  When they drafted the U.S. constitution, there was
  a huge debate over whether to base congressional representation on
  population per state or make each state equal.  Both sides had a good
  claim to the other being unfair; giving a smaller state (Rhode Island,
  or Mac users) equal say with a larger one can seem unfair to the
  larger segment, and I think in this case it would be.  ("No,
  seriously, guys, I think we should move the epoch to 1904.")
 
  I agree with jdb.  One equivalent vote per person opens the possibility
  that some company in Redmond could assign 250 of its employees to
  "go vote in that Perl thing and make it ours".

   Ouch.  Didn't even think of that.

Or, just as bad, the vote hits slashdot and we have a half-zillion frothing 
slashdotties descend on us and either vote their bigotries on us or just 
screw around for fun.

  Also, I'd point out a weakness in the presidential analogy for Larry.
  The President of the U.S. can only veto; any legislation he ignores
  passes by default.  Also, the President cannot introduce legislation.
  Rather, Larry is like a king; and we are his ministers, courtiers, and
  noblemen.  We can argue til we're blue, debate, resolve, and vote; but
  in the end, it's Larry who makes the decision.

   Yes, although Larry is kind of like a king after the signing of the
Magna Carta.  There's no divine right, here; if Larry decides we're
going to eliminate dollar signs for scalars and optimize the core for
a Cuse Python; module, most of us will jump ship.  (Though not
without tears of regret.)

I'll point out a bigger failing in the analogy. The US isn't a democracy, 
none of the states are (except for the odd dabbling in, usually badly, it 
with ballot initiatives), and very few municipalities are.

A better analogy is that Larry's the Bishop and Chief Architect, while the 
rest of us are engineers, sectional architects, artisans, craftsmen, 
journeymen, and apprentices, working to build up a cathedral. (And yes, I 
do mean this analogy in the way you likely think I do, amongst other ways)

Regardless, a "design decision by majority vote" just isn't going to fly in 
a mostly-volunteer effort, and it rarely does in a commercial effort. 
(Whether it results in a working system is a separate matter) If you need 
an example, we have Unicode staring us straight in the face. It was put on 
the table both out of general need and directly to serve a large part of 
the perl userbase (i.e. Windows), and look how far it got us. Heck, 5.6 was 
released as tatty as it was *because* people weren't working on the things 
that were unfinished.

If a proposal is put forth to handle personnel issues via some sort of 
community decision, that's great. If it gets Larry's approval I'm all for 
it and will follow the decisions it makes. (Even if, or especially if, the 
result is I take my leave) The one thing we should *not* do, though, is 
make design decisions by vote. It's worse than decisions via committee--at 
least those have some hope of being technically sound.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk




Re: Continued RFC process

2000-10-08 Thread Uri Guttman

 "NT" == Nathan Torkington [EMAIL PROTECTED] writes:

  NT I've heard people asking for RFCs to continue after the brainstorming.
  NT What do we want to do that we need RFCs for?  Design?  Implementation?
  NT Working out the fine details of behaviour?

well, this is the right time to open discussion on the next phase of
perl6. i think having the rfc's open to all was overall good but i wish
we had the infrastructure of the lists and stuff done before bootstrap
was created. the logjam there took forever to unclog. so let that be the
first lesson for our next phase. let's define it, its goals, and its
structure. then unleash the hounds.

some musings:

i think we need two major phases in parallel here. one is to generate a
decent coherent spec of the perl6 language. larry should lead that with
a strong hand. no flames from the unwashed masses on his choices. larry
could select teams and leaders to help him take the rfc's he likes and
to refine them into a proper spec. this should not be open to the public
except as read only. mythical man month is right here, we gave larry the
brainstorm, now we need a clean architecture given back to us. and
keeping with MMM's ideas, let's not fall into the trap of what to the
rest of us programmers do? first we all have our regular lives and jobs
to do so that is ok. but like he said, there are many other areas we
could work on like QA tools (schwern's bag), proof of concept code, etc.

the second part is internals. not to take anything from dan, but i see a
bottom up approach being very useful here. hammer out some
working/prototype vtable code, work on the new I/O subsystems (this is a
big project in its own right), work on byte code and related design
issues, etc. again, these teams should be led and staffed by people with
real experience in those areas. this should not be a public exercise
(again read only should apply to any outsiders).

waiting for larry (and the results of my business plan contest entry).
both due on friday. :)

just my $.02 for now,

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com