On Wed, 11 Oct 2000, Adam Turoff wrote:
[..]
> titled - RFC ## (v#): Add XYZ into Perl. That traffic is also easy
> to find in the archives.
>
> That will probably be less of an issue with a strong lack of RFC
> activity during the implementation phase. It very well could be
> that anyone doin
On Wed, 11 Oct 2000, Nathan Torkington wrote:
> Then again, remember the hassles we had with the perl6-* lists?
> Nobody knew how to deal with topics that overlapped lists. You had
> to know all the groups to decide which it was appropriate for. Are
> these big enough hassles to suggest that per
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 p
Nathan Torkington wrote:
> The immediate question facing us is how to structure software design.
> This is different from the ongoing maintenance of Perl.
> The architecture will be partially decided by Larry, and seems best
> done by a few experienced with such things. Detailed design seems
>
> "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
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 ABSOLUTEL
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.
>
>
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.
