RE: Continued RFC process

[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

[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

[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

[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

[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

[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

[John Porter]

David Grove wrote:
> 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.

Your paranoia knows no bounds.

-- 
John Porter

Re: Continued RFC process

[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

[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

[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

[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

[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

[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

[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

[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

[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

[Dan Sugalski]

At 06:58 PM 10/10/00 -0500, Tad McClellan wrote:
>On Tue, Oct 10, 2000 at 03:42:48PM -0400, Dan Sugalski wrote:
> > At 12:31 PM 10/10/00 -0700, Stephen Zander wrote:
> > > > "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? :)
> >
> > I was sort of hoping to go with Perl 6 Secred Decoder Rings, but a
>   ^   ^
>   ^   ^
> > handshake'd be keen too... :-)
>
>
>Would that be a Sacred Decoder?
>
>Would that be a Secret Decoder?

I'm not fnord telling... :-P

>Maybe it's not even a typo.
>
>Is it an attempt to create a new word so that you can be
>enshrined in etymologies throughout the world?

Argh! You're on to the master plan. Do please wave "Hi" to the Orbital Mind 
Control Lasers so we can take care of that little problem... :)

Dan

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

Re: Continued RFC process

[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

[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

[Nathan Torkington]

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 :-)

We should begin the cloning process for Larry immediately.  That way
it'd take an entire FLEET of busses to get him[1].

Nat
[1] I can just see the Python folks requesting a fleet of busses from
their corporate overlords :-)

RE: Continued RFC process

[Bryan C . Warnock]

> 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. 

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

Re: Continued RFC process

[Tad McClellan]

On Tue, Oct 10, 2000 at 03:42:48PM -0400, Dan Sugalski wrote:
> At 12:31 PM 10/10/00 -0700, Stephen Zander wrote:
> > > "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? :)
> 
> I was sort of hoping to go with Perl 6 Secred Decoder Rings, but a 
  ^   ^
  ^   ^
> handshake'd be keen too... :-)


Would that be a Sacred Decoder?

Would that be a Secret Decoder?


Maybe it's not even a typo.

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


-- 
Tad McClellan  SGML consulting
[EMAIL PROTECTED] Perl programming
Fort Worth, Texas

Re: Continued RFC process

[Daniel Chetlin]

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 don't know if it's the failings of MHonArc, or that xray is running an
old copy, or what ... but let's not standardize on xray. Please.

-dlc

Re: Continued RFC process

[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]) 

Re: Continued RFC process

[Russ Allbery]

Peter Buckingham <[EMAIL PROTECTED]> writes:

> I think that it is important that the developers have some free method
> of communication without being bogged down by insignificant details.

While I definitely agree with this, and I find the idea of focused,
read-only lists for core developers a rather fascinating idea, I do also
feel obligated to mention that the vast majority of free software projects
that I follow don't use this mechanism and seem to do okay.  Projects like
gcc and autoconf have open development lists and the signal-to-noise ratio
stays quite high.

I do feel obligated to mention that the one free software project that
does use a private list for core development, namely CVS (at least at some
points in the past), I found highly annoying.  But that was much more due
to the inability to read that list than the inability to post to it.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Continued RFC process

[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]) 

RE: Continued RFC process

[David Grove]

On Tuesday, October 10, 2000 3:51 PM, Simon Cozens [SMTP:[EMAIL PROTECTED]] 
wrote:
> 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.


Simon, it's corporate collusion and media control. Go understand what that 
means. The latter, at least, overrules the principles of Open Source by 
clouding truths.

There's an issue on the table being discussed. For the first time in a long 
time people's voices, not just mine, not just the P5P's, are being heard; and 
Perl has a _chance_ to be all the better for it.

RE: Continued RFC process

[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

[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

[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

[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

[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

[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

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

[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]> 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

[Will Coleda - IMG]

David Grove wrote:
> To those who don't know the old argument, which out of respect for the list and
> the listmaster I won't detail

Frankly, I think not knowing the details of the "old argument" makes it
more difficult to understand your stance. 

Is there an email archive of said argument somewhere?

Re: Continued RFC process

[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.

RE: Continued RFC process

[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

[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

[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

[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

[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

[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

[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

[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

[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

[Dan Sugalski]

At 12:31 PM 10/10/00 -0700, Stephen Zander wrote:
> > "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? :)

I was sort of hoping to go with Perl 6 Secred Decoder Rings, but a 
handshake'd be keen 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

[Ask Bjoern Hansen]

On Mon, 9 Oct 2000, David Grove wrote:

[public voting] 
> Good? Bad?

as someone who in a former life was part of creating news groups and
such I can only say bad things about "public voting" in an
environment like this. It just doesn't work and just doesn't measure
anything useful.

If you can answer 

  Who should be able to vote and why?
  How do you control that only those people vote?

then we can move on to the next obstacles. There is plenty to go.
The whole concept is just flawed. Votes like this is in best case
just a skewed opinion poll.

Besides, we already got consensus that we don't like it some months
ago on the bootstrap list.

 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

Re: Continued RFC process

[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

[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

[Nicholas Clark]

On Tue, Oct 10, 2000 at 02:20:23PM -0400, Uri Guttman wrote:
> 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.

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?

Nicholas Clark

RE: Continued RFC process

[David Grove]

On Tuesday, October 10, 2000 12:59 PM, Peter Buckingham 
[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. To accomplish a "community
> > contributed" Perl, this way of thinking, the elitism, the os-centrism,
> > the corporate control, must have checks and balances of some type.
> >
> > I don't disagree that the developers should have closed off lists.
> > However, I don't agree that the developers should be able to ignore the >
> > community within a closed-off little clique.. If they can, then a
> > "community contributed" and community based Perl is a farce, and cannot > 
be
> > otherwise.
>
> I think that it is important that the developers have some free method of
> communication without being bogged down by insignificant details. I see no
> reason that perl6-meta will not continue to be a free list so that people can
> discuss issues relating to perl. i would assume that the 'core' developers
> would
> continue to monitor it and address issues and concerns as they arose. i don't
> see how having closed lists for developers conflicts with having a 'open'
> discussion of perl and its current state and direction on perl meta. if you
> feel
> that someone or some group is taking perl in a direction that is bad you
> should
> be freely able to mount a storming of the bastille on perl6-meta.
>
> pretty much like you are doing now :-)
>
> so in short it seems like you agree that developers should have some low
> traffic
> mechanism of communication (a closed read-only list would seem to do this
> from
> my point of view), but you also want a mechanism to discuss where perl6 is
> going
> etc, i think that perl6-meta does this and will continue to do this (feel
> free
> to correct me)
>
> peter

No correction required concerning the last part. 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.

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.

Dan, I don't know you. I've never had any problem with you or your leadership. 
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 have no arguments with you. However, the possibility 
still exists, and always will, unless some kind of check/balance system is in 
place.

Re: Continued RFC process

[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

[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

[Peter Buckingham]

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. To accomplish a "community 
> contributed" Perl, this way of thinking, the elitism, the os-centrism, 
> the corporate control, must have checks and balances of some type.
>
> I don't disagree that the developers should have closed off lists. 
> However, I don't agree that the developers should be able to ignore the > community 
>within a closed-off little clique.. If they can, then a 
> "community contributed" and community based Perl is a farce, and cannot > be 
>otherwise.

I think that it is important that the developers have some free method of
communication without being bogged down by insignificant details. I see no
reason that perl6-meta will not continue to be a free list so that people can
discuss issues relating to perl. i would assume that the 'core' developers would
continue to monitor it and address issues and concerns as they arose. i don't
see how having closed lists for developers conflicts with having a 'open'
discussion of perl and its current state and direction on perl meta. if you feel
that someone or some group is taking perl in a direction that is bad you should
be freely able to mount a storming of the bastille on perl6-meta.

pretty much like you are doing now :-)

so in short it seems like you agree that developers should have some low traffic
mechanism of communication (a closed read-only list would seem to do this from
my point of view), but you also want a mechanism to discuss where perl6 is going
etc, i think that perl6-meta does this and will continue to do this (feel free
to correct me)

peter

RE: Continued RFC process

[David Grove]

On Tuesday, October 10, 2000 10:31 AM, John Barnette 
[SMTP:[EMAIL PROTECTED]] wrote:
> D'you think it's a possibility to provide read-only access to the lists
> for interested parties?

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. To accomplish a "community contributed" Perl, this way 
of thinking, the elitism, the os-centrism, the corporate control, must have 
checks and balances of some type.

I don't disagree that the developers should have closed off lists. However, I 
don't agree that the developers should be able to ignore the community within a 
closed-off little clique.. If they can, then a "community contributed" and 
community based Perl is a farce, and cannot be otherwise.

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.

Again, I absolutely insist what I've said elsewhere before, that programming 
the perl core on Tom's specific architecture, or someones specific OS, is not a 
proper qualification for "contributing" to the perl community. Many, many 
contributions would thereby be worthless and of no use to anyone. Many tens of 
thousands of man-hours would be irrelevant to this elitist mentality. There's 
more to Perl than perl.

We need to keep Perl moving forward, not just perl.

If the elitist mentality returns, we're no better off in Perl 6 than we were 
from 5.003 to 5.006, with the culmination of all bads being in 5.6. If the 
community is to have a voice, that voice cannot be silenced at the whim of "the 
powers that be". It is my understanding of Larry's wishes for Perl 6 that we 
move from completely oligarchical society to a completely (or at least 
generally) democratic one.

Re: Continued RFC process

[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

[Dan Sugalski]

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.

Dan

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

Re: Continued RFC process

[John Barnette]

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.

Nathan Wiger (Today):

> 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 prefer the exact criteria for "not actively contributing" remain a
> little fuzzy, since some people may really contribute for a good two
> months, then travel for 4 weeks, then contribute again. However, it
> seems reasonable that if someone's been on the list long enough for
> projects to come up that they pass on repeatedly, the list chair should
> have some type of authority to say "look, it's time you did something,
> or take off" (in fact, this could even be automated :-).
> 
> 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.
> 
> -Nate
> 

~ j. // A student who changes the course of history is probably
 // taking an exam. 

Re: Continued RFC process

[Nathan Wiger]

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 prefer the exact criteria for "not actively contributing" remain a
little fuzzy, since some people may really contribute for a good two
months, then travel for 4 weeks, then contribute again. However, it
seems reasonable that if someone's been on the list long enough for
projects to come up that they pass on repeatedly, the list chair should
have some type of authority to say "look, it's time you did something,
or take off" (in fact, this could even be automated :-).

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.

-Nate

RE: Continued RFC process

[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

[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

[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

[David Grove]

On Monday, October 09, 2000 9:39 PM, J. David Blackstone [SMTP:[EMAIL PROTECTED]] 
wrote:
>   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.

Uh, Nat asked for ideas. I gave one. Feel free to give a better one.

Re: Continued RFC process

[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 C 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

[J. David Blackstone]

> 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.

> In fact, I'd be uncomfortable thinking that my vote counted as much as,
> say, Ilya's.

  Yeah, me too.  That's why I prefer the current technical meritocracy
to this other proposal, even though I think it could work.

> 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 C module, most of us will jump ship.  (Though not
without tears of regret.)

  I feel compelled at this point to repeat a cliche: "Those who do not
know history are doomed to repeat it."

jdb

Re: Continued RFC process

[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

[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? )

> 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

[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

[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

[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

[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

[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

[David Grove]

On Monday, October 09, 2000 12:22 PM, Simon Cozens [SMTP:[EMAIL PROTECTED]] 
wrote:
> 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.

Public relations? Uh, who is the Perl 6 information officer?

You figure it out.

Re: Continued RFC process

[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

[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

[John Porter]

David Grove wrote:
> 
> Closing out the public sounds like what this is about, and that's very 
> Perl5ish, 

Well, everything you read is filtered through your own prejudices.
What Dan et al. are concerned about is basic engineering principles.
Imagine if every commuter who drives across the Woodrow Wilson Bridge
were allowed to dink with the design of its replacement.

[www.wilsonbridge.com -- No, you *can't* modify the blueprints.]


> 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". 

You yourself have ranted against splinter perls.

If there is to be One Perl, then the authority must be allowed to 
do its work, whether that's one man or a committee.  In the end,
those who differ with the decisions of the authority are SOL.
(Unless, of course, splinter perls are to be allowed.)

I also think that your fears that your own efforts toward the
development of perl6 will be spurned will ultimately prove to
be unfounded.  That's presuming, of course, you actually make
any efforts toward the development of perl6.  

-- 
John Porter

By pressing down a special key  It plays a little melody

RE: Continued RFC process

[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

[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

[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

[Dan Sugalski]

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.

Dan

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

Re: Continued RFC process

[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