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?
