On 05/13/12 08:57, Rob Weir wrote:
... Whew! I thought I was the only non-perfect person here ;-)
:)
But seriously, no large development effort can ever rely on perfect (or near-perfect) developers. That approach doesn't scale. We need to rely on an overall process that can efficiently find errors, and find them early. So I wonder, in cases like this, where we're upgrading a library that might cause functional regressions, whether we should do something like this: 1) Open a BZ issue for the task, e.g., upgrading a particular library. 2) In the issue, describe the general functionality that may be effected by the library upgrade 3) This then gives the QA volunteers a "head's up" that they should do some deeper testing in this area. (They probably don't read every message on ooo-commits) 4) It also gives us a place where we can look for producing release notes for 3.5. Does this make sense?
Makes perfect sense. In this case I reused BZ issue 115241 which already existed for the Lucene update. I didn't note it on the top as there were more changes going on. After committing the change (and this time the log was rather descriptive of the change) I added a reference to the commit as I always do. The issue, I think, is not really what to do but how to improve the workflow: I set the bug to RESOLVED FIXED. Is this the correct way to give a heads up for QA? Pedro.
