On Thu, Jun 10, 2004 at 11:33:51AM -0700, Eugene Kramer wrote: >I agree. In my previous company build process provided report in a format: > >bugID/changeID >bug description >developer, who fixed >developer's CVS comments associated with the fix >list of files modified for the bug > >This was a very effective way to communicate source changes, because it >provided the context for the change. It was all an in-house development. >This information is extremely valuable for QA, who can focus their effort >based on the list of modified files.
In our build process, we query Bugzilla to grab a list of bug numbers and dump them into a (mostly) auto-generated release note in our wiki. Then each bug entry in the table is a link to the appropriate bug page, and each of those pages contains the list of changes (file names, versions and checkin comments) needed to fix the bug. It works well for us... -- Steve McIntyre, Cambridge, UK. [EMAIL PROTECTED] "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
signature.asc
Description: Digital signature
_______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
