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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

[Dan Sugalski]

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

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

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

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

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

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

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

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

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

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

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

I should point out two things:

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

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

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


Dan

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

Re: Continued RFC process

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

[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

[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

[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

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

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

[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

[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

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

Now and then

[Nathan Torkington]

I think we're talking about two different periods of development here.

The immediate question facing us is how to structure software design.
This is different from the ongoing maintenance of Perl.

We want and need a small group to design perl6 correctly.  I can't see
this working any other way.  Software design is a completely different
process from maintenance, and it's unrealistic to expect the
maintenance model (big open mailing lists, everyone says what they
want) to work for an intently cerebral activity.

Design I'm seeing as in two parts: architecture (what are the major
components we need?) and detailed design (where each component has
an API designed and the interactions between components resolved).
The architecture will be partially decided by Larry, and seems best
done by a few experienced with such things.  Detailed design seems
appropriate for groups of 5-10 people in each area.  In both cases,
public viewing of the proceedings is mandatory (you can read their
messages and see their thoughts and comment in private).

Implementation is different from design, and different again from
maintenance.  If we do the design, test cases, and stubbing well
enough, we could have a cast of thousands doing the implementation.

I honestly don't see us arguing over design.  Or even over
implementation.  The big meat of this discussion so far seems to have
been how to prevent the ongoing maintenance of Perl from being
coopted.

I'm thinking about a team structure for ongoing maintenance.  Each
area (docs, stdlib, interpreter, compiler) has its own team.  A team
is only a few people: the person responsible for submitting patches,
someone responsible for keeping on top of user demands, and someone
from QA.  In some cases these roles might be shared, and there's no
law that says the same QA person couldn't be on several teams.  The
only law I'd want is that no team could be made up of people from
the same company.

In addition to these people is a release manager, coordinating with
everyone to set realistic deadlines and ensure everyone's talking with
everyone else.  No release goes out the door until all the teams agree
that they have a Good Enough product.  This way neither ActiveState,
Microsoft, nor the Trilateral Commission can dictate an unrealistic
release date.  And this goes both ways: if there is a dodgy release,
the blame can't be pointed at just one company.  At a team perhaps,
but there can be no accusations of coercion and manipulation.

I don't see voting having a role in any of this, except as a crude
opinion poll for the internal equivalent of Marketing.  Voting doesn't
work in the real world, and in an online world where you can't even
make someone respond to your email, I see it being even less
effective.

How's this sound?

Nat

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

Reading list

[Nathan Torkington]

I'd like a volunteer to research and HTMLify the reading list.  I
collected everyone's books (and will add my list when I get back to
the house).  I just need someone to dig up ISBN numbers, Amazon links,
and HTMLify it all into submission.

Mail me direct if you want to volunteer.  Thanks,

Nat

Re: Reading list

[Nathan Torkington]

Nathan Torkington writes:
> Mail me direct if you want to volunteer.  Thanks,

We have a winner!  No more calls, please.

Thanks,

Nat

RE: Now and then

[David Grove]

On Tuesday, October 10, 2000 8:03 PM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] 
wrote:
> I think we're talking about two different periods of development here.
>
> The immediate question facing us is how to structure software design.
> This is different from the ongoing maintenance of Perl.
>
> We want and need a small group to design perl6 correctly.  I can't see
> this working any other way.  Software design is a completely different
> process from maintenance, and it's unrealistic to expect the
> maintenance model (big open mailing lists, everyone says what they
> want) to work for an intently cerebral activity.
>
> Design I'm seeing as in two parts: architecture (what are the major
> components we need?) and detailed design (where each component has
> an API designed and the interactions between components resolved).
> The architecture will be partially decided by Larry, and seems best
> done by a few experienced with such things.  Detailed design seems
> appropriate for groups of 5-10 people in each area.  In both cases,
> public viewing of the proceedings is mandatory (you can read their
> messages and see their thoughts and comment in private).
>
> Implementation is different from design, and different again from
> maintenance.  If we do the design, test cases, and stubbing well
> enough, we could have a cast of thousands doing the implementation.
>
> I honestly don't see us arguing over design.  Or even over
> implementation.  The big meat of this discussion so far seems to have
> been how to prevent the ongoing maintenance of Perl from being
> coopted.
>
> I'm thinking about a team structure for ongoing maintenance.  Each
> area (docs, stdlib, interpreter, compiler) has its own team.  A team
> is only a few people: the person responsible for submitting patches,
> someone responsible for keeping on top of user demands, and someone
> from QA.  In some cases these roles might be shared, and there's no
> law that says the same QA person couldn't be on several teams.  The
> only law I'd want is that no team could be made up of people from
> the same company.
>
> In addition to these people is a release manager, coordinating with
> everyone to set realistic deadlines and ensure everyone's talking with
> everyone else.  No release goes out the door until all the teams agree
> that they have a Good Enough product.  This way neither ActiveState,
> Microsoft, nor the Trilateral Commission can dictate an unrealistic
> release date.  And this goes both ways: if there is a dodgy release,
> the blame can't be pointed at just one company.  At a team perhaps,
> but there can be no accusations of coercion and manipulation.
>
> I don't see voting having a role in any of this, except as a crude
> opinion poll for the internal equivalent of Marketing.  Voting doesn't
> work in the real world, and in an online world where you can't even
> make someone respond to your email, I see it being even less
> effective.
>
> How's this sound?
>
> Nat


Corporate and diplomatic, but worth a shot. If it even has a _chance_ at 
keeping fair play in the community, I'll support it. It apparently does, though 
I'm wondering how different this is from the current setup.

Points of clarification, however. QA team determines definite preparedness for 
release? No two or more members of a single company on (QA Team|Any Team)? If 
any team, for the purpose of development, it's not entirely logical/feasable, 
is it? For the purpose of determining the quality of a potential release or 
code fix, etc., it's one step in the right direction. Would this team be able 
to return crippled features to developers for rethinking (extending, 
embedding)?

Thanks again for your tolerance and even-handedness, Nat.

Group: I have now had seventeen requests to fork perl from people other than 
"elitists" apparently joking (?) about it. The answer is ABSOLUTELY NO. Stop 
asking. If _YOU_ fork it, don't consider yourself any advocate of Perl or this 
community! The problems in this community are not solved by secession. Even if 
it were technically feasable, it's absolutely disgusting to me, and I'll have 
no part of it. I wish it were politically correct to curse!

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

[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

[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: Now and then

[Dan Sugalski]

At 08:50 PM 10/10/00 -0500, David Grove wrote:
>Group: I have now had seventeen requests to fork perl from people other than
>"elitists" apparently joking (?) about it.

I haven't been. I don't think anyone else has either. It's not a joke, and 
it is a valid thing to do.

>The answer is ABSOLUTELY NO. Stop asking. If _YOU_ fork it, don't consider 
>yourself any advocate of Perl or this community! The problems in this 
>community are not solved by secession.

That's a rather absolutist and silly thing to say. Sometimes secession *is* 
a valid option. In some cases it's a better option. I'd far rather that 
someone with a profound difference in opinion of the direction of 
development fork and go off on their own, rather than either stay and make 
lots of folks (including themselves) miserable or having the community as a 
whole lose them.

Forking isn't bad. The world's certainly not a worse place for having all 
the various BSD and SysV Unix forks. (Most of the commercial Unices 
qualify, as do the *BSDs) Neither is it a bad place for having the GCC fork 
not all that long ago.

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

[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

[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

[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: Now and then

[Uri Guttman]

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

  NT> Implementation is different from design, and different again from
  NT> maintenance.  If we do the design, test cases, and stubbing well
  NT> enough, we could have a cast of thousands doing the implementation.

cecil b. demillions of coders.

  NT> I'm thinking about a team structure for ongoing maintenance.  Each
  NT> area (docs, stdlib, interpreter, compiler) has its own team.  A team
  NT> is only a few people: the person responsible for submitting patches,
  NT> someone responsible for keeping on top of user demands, and someone
  NT> from QA.  In some cases these roles might be shared, and there's no
  NT> law that says the same QA person couldn't be on several teams.  The
  NT> only law I'd want is that no team could be made up of people from
  NT> the same company.

that resonates with MMM totally. look at the surgical team approach as
well but updated. each group has a lead and a 2nd (and possibly 3rd) in
charge. others in the group do work on various parts under control of
the group leaders. support types like QA, version control, docs
management, can be shared among groups.

  NT> In addition to these people is a release manager, coordinating
  NT> with everyone to set realistic deadlines and ensure everyone's
  NT> talking with everyone else.  No release goes out the door until
  NT> all the teams agree that they have a Good Enough product.  This
  NT> way neither ActiveState, Microsoft, nor the Trilateral Commission
  NT> can dictate an unrealistic release date.  And this goes both ways:
  NT> if there is a dodgy release, the blame can't be pointed at just
  NT> one company.  At a team perhaps, but there can be no accusations
  NT> of coercion and manipulation.

damn, i wanted to use my trilateral connections to fork perl in my
way. all my rfc's ROOL! :)

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