2009/10/28 Adrian Klaver <aklaver@comcast.net>:
>
>
>
> ----- "Guillaume Lelarge" <guillaume@lelarge.info> wrote:
>
>> Le mercredi 28 octobre 2009 à 15:13:06, Thom Brown a écrit :
>
>> >
>> > Similarly: "Fix encoding handling in binary input function of xml
>> > type." What was the problem before?
>> >
>
> See attached screen shot for one possible solution.
>
In other words we need to scour the committers mailing list to hunt
for this information? This is exactly my point. Testing doesn't
appear to be well organised. In my last place of work we had a set of
requirements, technical solution design and a test guide which
instructed testers on what areas need testing. From these a test plan
was built to ensure that the requirements were met, and that the
technical solution was working as specified. In addition to this they
performed regression testing in the affected areas to ensure
everything else still worked as expected and wasn't negatively
affected by the new changes.
All we have are a summary of changes. We can find out all the
information if we do plenty of searching of mailing lists and
comparing old and new documentation, but obviously this can be
off-putting and is duplicated for everyone who wants to participate in
testing.
I'm suggesting that while this is technically sufficient, it might be
a better idea to provide a clear technical document of the changes
that have been committed.
Such documentation may also potentially be reused when the final
version is released for end-users to review for any changes they might
need to make to their existing code and queries to ensure they don't
break.
Obviously PostgreSQL has survived very well without this, but I would
expect this would help more users perform more testing.
Thom
