Kristis, I'm not sure this bug/feature request is a good idea.
>From a process/QA/best practice point of view, a checkin to a code repository should be autonomous. Having a different checking message for different bugs, and potentially different status changes, to me sounds like it should be multiple checkins, even if you take the bug tracking out of the equation. Especially in an agile environment, the best practice is for small checkins reguallarly. This helps with auditing changes, identifying problems in testing, and also makes roll-backs/revertion easier. Obviously, there is a case where a single code fix will fix multiple bugs, but I do not see a reason why both bugs should not have the same information stored in the bug database in this case, as the 2 bugs are clearly related (otherwise they should be separate check-ins), and so a tester needs to know about both issues when re-testing and determining the risk associated. Obviously I am biased, but I think simplicity in any process is the key. Robert. Robert G Ward QA Manager Site Intelligence Ltd. e [email protected] -----Original Message----- From: Kristis Makris [mailto:[email protected]] Sent: 28 October 2009 8:58 PM To: Robert G Ward Cc: 'Steve Sowerby'; [email protected]; [email protected] Subject: RE: [scmbug-users] Scmbug with Bugzilla 3.4.1 - status changing Hi Robert, Steve, On Wed, 2009-10-28 at 17:45 +0000, Robert G Ward wrote: > Kristis, > > Thanks for the mail and considering our case. > > I like that idea. The reason we implemented this our way was so that > we did not have to enter the bug ID's multiple times. If the check-in > does not resolve bug 744, then I'm not sure we would include it in that checkin. > > Something closer for our needs would be as follows: > > bug 547,600: Implemented automatic status resolution as a new policy. > This seems to work but will need improvements in the testsuite. > status: RESOLVED FIXED > > ie, if there were no-bug id's defined for the status change, then the > status change is applied to the bugs defined in the first line. This, > I think, would be a more useful scenario, and easier for the developers to do. I like the simplicity of this scenario. One concern is that, ideally, we'd like to also allow a single commit to potentially provide multiple log messages -- different per bug: http://bugzilla.mkgnu.net/show_bug.cgi?id=647 Thus the work in bug 647 could conflict with this scenario you are proposing, especially if the user gets into the habit of not supplying the bug numbers for the status resolution. Nevertheless, it seems possible to assume that if only a single commit message and single status resolution description are found that the status resolution corresponds to the bug numbers. This is worth investigating. Thanks again for your feedback. _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
