Front page | perl.perl6.internals |
Postings from February 2002
Re: PDDs, guys.
Thread Previous
|
Thread Next
From:
Josh Wilmes
Date:
February 17, 2002 19:06
Subject:
Re: PDDs, guys.
Message ID:
200202180306.VAA09940@sky.net
Bravo!
PDD 7 (coding standards) is also still MIA, although i understand that it's
basically complete.
--Josh
At 16:18 on 02/17/2002 GMT, Simon Cozens <simon@netthink.co.uk> wrote:
> I was just starting to think about writing something on the history and
> evolution of Parrot's design, and came across some PDDs in the mail archives.
> Grief, I remember these things! These were meant to document the design,
> what we'd decided, why those decisions were a bad idea, what we chose instead
,
> and so on. They were also supposed to help ensure that everyone knew what
> we were working on and how it all fit together.
>
> Needless to say, we stopped using them. This seems sad, and, after the recent
> confusion (completely my fault) about how keys should be implemented, really
> quite silly.
>
> I know I'm the worst offender in terms of hacking the source without really
> telling people what I'm doing, so I'm going to fix this by pushing out a
> couple of PDDs in the near future.
>
> COMMITTERS PLEASE NOTE: I'd like you to ensure that any changes you commit in
> the future, whether by yourself or anyone else, has an associated PDD. When I
> say "any", I expect you to use your discretion - things to fix up warnings,
> typoes, minor alterations and so on don't need documentation to go along with
> them; changes which alter or create subsystems *do*. I consider this at least
> as important as tests, if not more so.
>
> I don't want to single people out, because we've *all* been pretty crap about
> this, but I notice we have a bignum implementation and bits of an IO subsyste
m
> in there without any associated documentation. This, bluntly, sucks. Alex,
> Melvyn, Ton, etc. I'd like to see PDDs for your stuff as soon as you have tim
e
> to write something. Start small, so we've got *something* to look at, and add
> detail later at leisure.
>
> On the other hand, I don't want to make PDDing an onerous requirement. Here's
> what I propose:
>
> 1) All the PDDs go into the CVS repository (We give Ziggy CVS access so
> he can tweak these where necessary.)
>
> 2) Brand new stuff has to have a PDD put in the repository *first* -
> create a PDD, discuss it, send it to Ziggy and have him number it and put it
> in the repository.
>
> 3) Patches which change the design of something also include a patch to
> the PDD, which changes the version number and adds an entry to the "CHANGES"
> section (adding it if it doesn't exist) stating either:
> what was wrong with the old design and how you fixed it, (if you're
> changing something)
> or
> what you've just done AND WHY. (if you're adding something)
>
> oh, and a datestamp and email address thingy.
>
> In case that's too onerous, just one or two lines saying what you did would
> be better than nothing at all.
>
> But please, let's use these things. I firmly believe that these will speed
> up the process, rather than slow it down. At the moment, the way I want
> certain things done is only stored in my head and Dan's head. This means only
> Dan or I can implement them. If we share our ideas, other people can ship in
> bits. If we're really lucky, Dan and I won't have to write any code at all. :
)
>
> Yes, I'm being an anal retentive asshole. It's my job.
>
> Simon
>
> --
> "Do not meddle in the affairs of cats, for they are subtle and will piss on
> your computer." --Bruce Graham
Thread Previous
|
Thread Next