2009/10/28 Adrian Klaver <aklaver@xxxxxxxxxxx>: > > > > ----- "Guillaume Lelarge" <guillaume@xxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
