On Wednesday, October 11, 2000 11:02 AM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] 
wrote:
> David Grove writes:
> > I'm wondering how different this is from the current setup.
>
> Currently there's the pumpking and the pumpking decides when to
> release a new version of Perl.  This exposes the pumpking to all sorts
> of allegations, and potentially exposes Perl to being bought out.
>
> When no single person can force a release through, both problems go
> away.  It's distributing the current pumpking's responsibility
> (integrating patches, quality control, communication and deadlines)
> to more people.  This has the added benefit of hopefully avoiding
> pumpking burnout.
>
> > Points of clarification, however. QA team determines definite
> > preparedness for release?
>
> It's a joint decision.  If QA likes it, but the code person doesn't,
> they have to sort that out between themselves before the release can
> happen.  If the user liaison says "we've been promising this for the
> last three releases, we can't make another release without it" then
> the others have to listen.
>
> But nothing can be released without QA's approval.
>
> Nat

Yes, that satisfies my concerns by providing "checks and balances" to the 
system.

Bjarne Stroustroup in "The Design and Implementation of C++" talks about ANSI 
and the C++ committees, and how he's always tried to get real strings into the 
language as a basic data type, but every time he brings up the subject either 
Dennis Ritchie or a chinese lady whose name escapes me raises her hand and with 
that it's all over. The setup there is that it has to be unanymous. The need 
for unanymity slows down the process, but provides for a completely stable C++ 
implementation. I'm not sure that unanymity wouldn't be going overboard for 
Perl, but that would be a decision internal to the QA group, correct? Or 
something determined by Larry? There's definite pros and cons each way. 
Basically, the cons are that some things would never end up in the perl core, 
and the pros are that certain things would never end up in the perl core, like 
temporary and experimental "fixes" that don't work implemented mainly for a 
marketing stunt and that have the byproduct of disabling major features of the 
language...

Have I tangented with this, or are we still making sense to each other?


Reply via email to