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 

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.

Reply via email to