> 1 - To set your custom bugzilla field, look at > Daemon/Integration.pm:change_resolution_in_all() which calls > Daemon/Bugzilla.pm:integration_change_bug_resolution. You need to > extend change_resolution_in_all to also issue an > integration_set_custom_field, which you must add in Bugzilla.pm, to set > the field > > http://bugzilla.mkgnu.net/show_bug.cgi?id=1183
Thanks for the pointers. I'm attempting to grok now. > > NOTE however that a "fixed" bug may have work done on it among various > tags. You may tag 4 times, and have changes in all those 4 times before > you finally fix the bug. Be aware of this if you choose to follow this > route. Also, you may "fix" bugs without any SCM activity on them (e.g. > you debugged a bug report and concluded there's no bug and that's > expected behavior). We don't currently use tags per se. We do use branches, and if a bug exists in more than 1 branch, it gets cloned, so there's a unique bug id for each branch. > 2 - Perhaps the VDD only requires tags to be given as input for "from" > and "to", but tags correspond to revision numbers -- maybe what you are > really asking is ... that we improve the VDD to support this! You > would need to look at Tools/VDD_Generator.pm for that. Is 'HEAD' a valid name to use ? > NOTE again that the VDD is quite more capable than what you asked for > in (1). It can show bugs fixed between revisions, bugs worked on > between revisions even though they have not been fixed, new bugs added, > bugs closed *without* any SCM activity on them, etc. The VDD document > can be futher tailored by copying and customizing: > > /usr/share/scmbug/glue/templates/stylesheets/vdd.xsl > > ...so that you can have the VDD display only parts of all these things > (e.g. only bugs fixed, and bugs fixed with no SCM activity) > I haven't started playing the the vdd yet. We only have at this point 2 integration activities recorded so I didn't think it would tell me much. That could stand a little more documentation too, maybe an example. Side rant: I love open source software. I hate the documentation that comes with it. Nobody like to write them (myself included), but if we want anyone to use our spiffy new tool, we have all got to get better about it. Yours is pretty good as these things go. IMHO it would benefit from a little better logical organization, such as all the installation stuff in one section, and a few more examples. Here we use nant and CruiseControl.NET, and let me tell you. Both are insanely frustrating to try and learn how to use from the documentation provided. > The long-term "fix" in my opinion is that the VDD Generator should be > corrected to produce this information, but this can be quite some work > because the backends expect tag names (versions) instead of revision > numbers for the tags. e.g. look at Bugzilla.pm:integration_get_vdd > > http://bugzilla.mkgnu.net/show_bug.cgi?id=947 > > I'm afraid you are touching on issues we haven't ironed out yet > implementation-wise. That would definitely be a great addition. Once this place settles down from 'early-stage startup insanity mode' to 'something resembling a normal work schedule' mode I'd be interested in contributing. I think this is a cool project with a lot of potential. Maybe if I finally convince them to switch to Perforce I can help develop the glue for that. Drew _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
