Hi Robert, Bug 647 has had a patch pending by Kira for four years now. I admit I hadn't become convinced about how useful it might be, although James showed interest in it recently.
I agree with Robert that small regular checkins are a great practice, and it is what I follow, but it may not be the model followed by others. Kira and James, perhaps you have some thoughts on this ? On Thu, 2009-10-29 at 09:21 +0000, Robert G Ward wrote: > 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. > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
