On 2001.07.18, Jerry Asher <[EMAIL PROTECTED]> wrote:
> Is there some magical technical solution? How do other developers or
> projects handle such things?
>
> (Please no comments about not making big/broad patches in the future.
> Sometimes, it just doesn't seem possible to take big additions of
> functionality and distribute then as a small patch.)
I follow a simple practice, here at work, that sums up to something
like: "If you can't explain something, you probably don't understand
it well enough to have gotten it right."
Explain what your patches do -- what they fix, what they enhance, what
existing functionality they change. Compliment your explanation with
specific test cases -- (preferably executable, whether automated by the
machine or a step-by-step that a human can follow and reproduce -- that
demonstrate what happens before your patches, and what is to be expected
after the patches.
This will give others enough to go on to understand what your patches
are supposed to do, and verify that the patches actually accomplishes
what you say they do. Otherwise, the amount of time it'll take someone
to just take the output from 'diff' and (1) figure out if your change
actually improves things instead of breaking something that already
works, and (2) actually implements the change correctly ... well,
that's very time consuming.
This is just my two cents. I don't work for, or speak for, AOL
or anyone other than myself for that matter. Jim, Kriston, or
anyone else from AOL will have to give a more official response to
your questions.
-- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
