On Tue, Feb 20, 2001 at 08:47:58AM -0500, Bryan C. Warnock wrote:
> On Monday 19 February 2001 22:18, Edward Peschko wrote:
> > Speaking of which... apologies in advance for cross-posting this, but I
> wanted
> > to get the largest audience possible... I won't do it again. At least not
> in the
> > forseeable future.. ;-)
>
> Yes, "forgive me father, for I'm about to sin....."
> If it warrants an apology, don't do it.
Unfortunately, some sins are worth doing. This is one of them. I gauged that the
larger audience was worth the flak that I would get. I think I was right.
> Well, yes, but that was rather the point, wasn't it?
No I don't think that's true.. I think that RFC's are much more powerful if they
work at least somewhat in concert. At the very least, the knowledge of the other
RFC's help come up with new ideas...
> The RFC process wasn't meant to be comprehensive or unidirectional - it was
> a feeder system for the start of Perl 6. Each RFC wasn't a community
> effort, beyond what feedback the author got, and couldn't really be
> expected to be complete. Each RFC was also proposed in a vacuum - each
> functionality was standalone - unless the author happened to have written
> another fifty RFCs or so that they could tie into - so there was no way to
> give a true representation of implementation. The RFCs addressed general
> models for Perl 6 direction, or directions, since there was no specific
> Perl 6 definition to target for. The RFC stage was designed for what folks
> were passionate about - the most important changes - not an
> all-encompassing picture of Perl 6. It was prep work. It was pre- and
> mid-construction bracing. It was just one stage in the life of Perl 6.
> It should be left alone as is, if only to segregate all v2 process from the
> v1 process.
But that's the point - as it is, the RFC's are an insufficient source of
raw material for the v2 processes that you describe.
I think of RFC's as 'high level design'. The PDD's that you are describing
are low-level design, reality chipping in after reading all of the RFCs and
deciding how to implement them. And I don't think that PDD's should be
shoehorned to fit both roles.
And look at it this way. RFC's were an experiment that was *very* successful. Or
at least very popular. 361 RFCs, just by the count of them is a smashing
success.
No, I think that there really should be two levels of docs. One, a scratchpad,
the second a 'lets do this, here's how we are going to do it.' type of doc.
And one can be the starting point for the other.
> What you are looking for is the (slightly misnamed) PDD, which I<is>
> supposed to be the "end-all-be-all" of Perl 6 (and Perl, to some extent).
> It is supposed to a community-driven, comprehensive, living record of what
> is (and was) Perl.
Again, I don't think that *is* what I'm looking for. I think that RFC's
could be a very convenient way of reducing the amount of redundant traffic on
mailing lists, as well as standardizing the dialog. And as I said, I don't think
that *either* the RFC's or the PDD's should be 'comprehensive'. That's asking
too much.
I'll clarify these points in the RFC.
Ed
