Remember the convenient way SGI's ptools revision control system was tied to the pv bug system, so when you checked in, if you put the bug number in the subject line, the bug was automatically closed with a note about the checkin? Wouldn't it be great if we could do that too? Put some code in the cvs checkin message, for example, if I put FIX 1234 or PARTIAL FIX 1234 in the bug message, then bug 1234 would have a note appended to it noting the date, the files and the rest of the checkin message, and if it was FIX rather than PARTIAL FIX, the bug would be resolved as FIXED at the same time. This would help QA, too, since they're always asking developers to note when particular checkins were made to fix bugs, so they know which builds should have the fix, and we're always forgetting to make that information explicit.

That is a very interesting idea. There is just one problem with this that I can see though, namely, it would introduce a dependency, making Bugzilla dependent on a specific source control tool (in this case, Bonsai). Since one of the beauties of Bugzilla (IMO) is the fact that it is easily adapted to *ANY* open source project with a development model like this (other Bugzilla users now include Red Hat, Abisource, and the Hungry Programmers, to name a few), I think it would be nice if one could find a way of adding this feature, but doing it in such a way that it wouldn't be too hard to adapt it to whatever tree control tool you wanted to use (though it is hard to imagine anyone wanting to use something better than Bonsai, IMHO).

I would at the very least make sure that Bugzilla would work without Bonsai or without CVS. You may not get this feature, but I certainly won't make the whole system depend on CVS or Bonsai.

terry, is this a Won't Fix?

No, this is a wishlist item. I've been hoping to do it for the last couple of years, even back in the days when I used BugSplat instead of Bugzilla.

Hi; I've been working on adding this feature to Bonsai/Bugzilla, and it seems to be working now. It's still in the local alpha-test stage, and the bonsai side is for the old Tcl-and-Perl version, but I thought I'd let you know anyway, just in case anybody else has been working on it... Expect patches in a week or two, maybe.

Hot damn! Thanks!

OK, here comes an attachment which is the patches to add this feature. It's a tar.gz file containing some patches, a new script and a README; look at the readme for the gory details. Hope this helps :->

Pretty cool stuff. Some comments: First, it looks like you've ported to the new Perl-only version of Bonsai; cool! Second, rather than making everyone register their CVS account, I would hope that we could instead have a configurable mapping from CVS accounts to Bugzilla logins. In the two bugzilla systems I administer, there is a pretty direct mapping, and I wouldn't want to make my users have to worry about this at all. Third, your new process_auto script has a fair amount of overlap with the existing process_bug script. And, in fact, it needs more; you put in a comment that says "don't need to check for ... dependency loops", but you do need to do some dependency stuff. (Any bugs that depend on a newly closed bug get email notifications.) I think that most of process_bug needs to get pulled out into a new separate script, and process_bug and process_auto would both become fairly short scripts that include that new script.

As far as the CVS ID stuff goes, part of the reason for making people put in their CVS ids is because we didn't want peoples' CVS logs to suddenly have magical effects without their having explicitly asked for it... If you want to enable it automatically, you could just make the new-registration bit put in a suitable initial value for the cvsid field when it puts the entry in the profiles database. Turning off the 'usecvsid' field in the config will simply remove that section from the configuration page. (Or you could add a 'yes/no' toggle if you wanted.) None of this would be difficult, but making it completely customisable would be a bit of a pain... re: the dependency stuff in process_auto : I freely admit to not having completely understood that bit :-> (and we don't seriously use dependencies here (yet) anyway).

Oh yes, forgot to mention a known deficiency: If you make a checkin on files foo/bar.c, foo/bar.h, baz/baz.c [say], then addcheckin.pl will be invoked twice, once for (foo/bar.c and foo/bar.h) and once for baz/baz.c. (ie once per separate directory in the checkin). So the bug will have two comments appended to it, one listing the files changed in directory foo and one listing changes in directory bar. I can't see any easy way of getting around this. It might be possible to have the CVS server invoke dolog.pl at a different point in the commit process (in 'commitinfo', maybe? I'm not too up-to-speed with cvs server stuff...) to get it to send a single email to bonsai per checkin. Otherwise you get into nasty heuristics like holding on to the bug-change for x minutes to see if another similar one comes along...

*** Bug 22945 has been marked as a duplicate of this bug. ***

so there hasn't really been any activity here for a while. maydell, have you gotten your patches back to terry? Even if we could just add CVS comments to the relevant bugzilla bug, that would be awesome

I submitted my patches to this bug report on 1999-07-29. I'm aware that there were some minor problems/deficiencies with them, but since they 'worked for us' I never got round to actually cleaning them up at all [I'm not paid to do Bugzilla stuff so I can't justify spending too much time on it.] As I say, it works for us, and I use it all the time to add CVS log remarks to bugs. The automatic-closing also works, modulo the problems with dependencies, but in fact my company has just changed to requiring that bugs not be fixed directly by the CVS checkin, so you can give a general overview comment when actually closing the bug (rather than the low-level detailed remarks that tend to be in CVS comments.) It would also be nice to be able to abstract the syntax used to mark CVS comments as fixing bugs, so it could be set on a per-site basis...

I notice that the process_auto script as attached to this bug has drifted out of sync with the latest Bugzilla sources (in particular, the new longdescs table breaks it). I had a go at merging the common stuff from process_auto and process_bug, but have given it up as Too Hard. In particular, the code in process_bug to modify the database is inextricably intertwined with the user interface (HTML generation) code. It doesn't help that it uses %::FORM both to note what changes the user wants to make to the bug and to store the state of the parts of the bug that aren't being changed. It could also use more comments :-> I've therefore given up on doing anything more than keeping our local modifications working with whatever Bugzilla version we happen to be using. If anybody else wants to get this functionality into the main Bugzilla sources they'll have to do the grunt work themselves.

tara@tequilarista.org is the new owner of Bugzilla and Bonsai. (For details, see my posting in netscape.public.mozilla.webtools, news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)

we were having a discussing about this at Blue Martini some time ago, and I remember there being a whole bunch of gotchas we came up with as to why this will be hard. Hrm..... I'll check out the patches and ponder this some

*** Bug 40683 has been marked as a duplicate of this bug. ***

Adding this comment plus patches for a new submitter: added following line to rcsinfo to define a checkin template for the user to use DEFAULT /src/master/CVSROOT/msgtemplate msgtemplate created in CVSROOT and contains only one line BugIDs: The combination of rcsinfo and msgtemplate prompts the user to enter a bugid number or numbers seperated by commas when they commit. added the following line to loginfo ALL (echo ""; cat; echo %{sv}; echo $USER; date) | /bugzilla/CVSInt.pl this sends the cvs log message, file and new version numbers, the user committing, and the date to CVSInt.pl (attached) CVSInt.pl takes inspiration from whineatnews.pl, show_bug.cgi, and bug_form.pl. In short CVSInt.pl takes the passed information, changes the format, pulls the bug id's out, queries the bugzilla database for the bugs, and sends e-mail to the owner of the specified bugs (in our case usually the same person commiting the files). The owners then get the e-mail with a URL that includes the CVS comments. The user can then open the URL see the CVS commit in the comment window and mark the bug as fixed. to get the comments to appear by opening the URL I made changes to bug_form.pl. Here is a diff of the files (bugform.pl also attached) [root@testlinux dbeek]# diff mybugzilla/bug_form.pl bugzilla-2.10/bug_form.pl 166,176d165 < sub formvalue { < my ($name, $default) = (@_); < if (exists $::FORM{$name}) { < return $::FORM{$name}; < } < if (defined $default) { < return $default; < } < return ""; < } < 366,368c355 < <TEXTAREA WRAP=HARD NAME=comment ROWS=5 COLS=80>" . < value_quote(formvalue('comment')) . < "</TEXTAREA><BR>"; --- > <TEXTAREA WRAP=HARD NAME=comment ROWS=5 COLS=80></TEXTAREA><BR>"; Also made a new field in defparams.pl, Here is the diffs for that file (also attached) [root@testlinux dbeek]# diff mybugzilla/defparams.pl bugzilla-2.10/defparams.pl 382,404d381 < DefParam("cvsmail", < "The email that gets sent to anyone who makes a CVS checkin and indicates the bug numbers in the BugIDs section. Within this text, %email% gets replaced by the bug owner's email address. %<i>anythingelse</i>% gets replaced by the definition of that parameter (as defined on this page).<p> It is a good idea to make sure this message has a valid From: address, so that if the mail bounces, a real person can know that there are bugs assigned to an invalid address.", < "l", < q{From: %maintainer% < To: %email% < Subject: Your Bugzilla buglist needs attention. < < [This e-mail has been automatically generated.] < < You have one or more bugs assigned to you in the Bugzilla < bugsystem (%urlbase%) that require < attention. < < A CVS checkin has indicated that the bug assigned to you may have been corrected. < < Verify the bug has been corrected. If you made the CVS checkin open the URL < to the bug, change the status of the bug to resolved, and mark the bug as fixed. < < Appended below are the individual URLs to get to all of your bugs that < were indicated in the CVS checkin. < < }); < I had to tweak some of the group permissions so a CVS user is able to execute bugzilla scripts. Anyway I hope these are considered valuable contributions and included in future releases of Bugzilla. With minor changes a CVS import could be disallowed if a bug doesn't exist. Something I'm sure my manager will have me do.

Arggg. His patches are now slightly out of date. We'll now pause while I wait for some further info so I can actually publish the patches.

reassigining to me.

so just to let people know where i am. i am completely rewriting Bug.pm so that it is general enough to be called from any perl script. there will be enough support so that you can get bugs from the database, modify them, and commit the changes and do all of the necessary collision checking, dependency notification, and e-mail notification. i'm probably two weeks away from releasing something for people to start testing with.

okay, here is where i am with this: if you checkout CYEH_20000628_BRANCH of Bug.pm, you'll notice a whole slew of code that pretty much allows you to create new bugs, change fields, and then commit them back to the database. this code has bugs in it. this code doesn't do anything with dependencies or the cc list. but it's good enough if you want to do something simple like change status flags around and then committing the changes. i have no timeline on when i can finish this up and merge this to the trunk.

Taking all of cyeh's Bugzilla bugs.

looks like the interesting stuff here is actually in cvs on cyeh's branch. We should look it over at some point.

Moving to New Product Bugzilla

Urgh. Implementing this would be icky, and the only gain would be to encourage programmer laziness. Gerv

I see no reason to implement this specially in Bugzilla. No need to introduce a dependency! CVS is already set up to handle emailing on checkins (I use it that way for Bonsai). If we simply have a perl script in contrib/ which people could tack onto the end of their loginfo file in CVSROOT, which in turn mails the Bugzilla email interface, we can close the bug. I don't think the email interface allows bug closure through the mail right now, but that's something I could fix quickly enough I think. Since email is so crucial to the rest of webtools anyway, I see no reason we couldn't use it easily this way without creating a new dependency or hacking a bunch of code. Myk, I'm going to go ahead and take this bug if that's OK : ) I have other fixes to Bug_email I need to put in anyway...

Morphing bug to turn it into what Barnboy wants to use it for. Gerv

If you do have time to implement this, please add a comment for those of us who just stumble along in CVS on how to get it to send the automated mail. Thanks! I agree that using existing mechanisms as much as possible is the right way to go (I just didn't know CVS already had this ability).

We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.

Gerv, Matthew, has the absence of this feature encouraged engineers to do redundant (but apparently character building) work? No. As Alec also requested, we should *at least* post a comment in the relevant bug. That should be possible without creating any bugzilla dependencies or large enhancements. I filed 129765 just to get the comments into the bugs. Perhaps that's a dup of this, but I hope it can be done without dependencies on bugzilla changes or emails.

per the above comments, adding dependency on bug 122922, which was opened to get the Bug.pm from cyeh's branch completed and pushed onto the trunk.

barnboy has a new email

Hi, I would like to bring the discussion away from cvs/bonsai or whatever you are using for source control. The point is not that bugzilla needs some integration into something else (other peoples work!!), but bugzilla needs other systems/tools to be able to set status/resolution fields automatically. In one project e.g. here at Condat we use a somehow automatic software integrator, that integrates new code into the baseline, compiles, starts the software and does the automated testing. If anything fails, the patch (integration request) is rejected else it is included into the baseline and the bug report needs to be set to "resolved" to inform QA to include the PR into handish testing of then next test candidate. So I think we are not alone in having the need for some "well structured" way to tell bugzilla a status/resolution should be changed. (maybe by keywords, maybe in XML-Format, or however it fits best to bugzilla ....) It seems to be somehow familiar with the move mechanism to me...btw. thanks, Holger

After a long time away and some deep thoughts, it certainly seems bug_email.pl is not the way to get CVS status updates into the bug. XML seems to be the way to go... do we support modification of bugs via XML, or only import/export? I think a checkin script along with some modifications would do nicely without modifying Bugzilla to tie it directly into CVS. Taking bug again; it looks like an interesting project to me now :) At the very least, CVS could be a user in the system, log in to Bugzilla, add its update using POST, etc. It's a CVS issue, and not a Bugzilla issue, except for perhaps providing some standard way of scriptable bug transitions.

Matt, you and Erik probably want to get together on this

Comment on attachment 1036 [details] Tar file: patches, README: fixes this bug denying review based on comments in bug. (really old patch, we didn't have review flags back then :)

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.

I have implemented something vaguely similar to this in a PHP script. The script merely checks an IMAP database at a set interval, grabs messages from it, parses them for any bugzilla commands (resolve, close, or add to comments), then performs the action directly to the database. It's by no means a fix to this bug, but it will hopefully provide an adequate workaround until it is solved. There's lots of problems with it; the most glaring one being that there's no way to verify that the From: email isn't spoofed. This makes it somewhat useless in a public environment, but it is currently in use on our company intranet and works great. Hopefully someone can think up a decent auth mechanism. I'll post it within a week once I've worked out a few kinks.

the assignee seems pretty inactive

This is related to by request for an robot interface in bug 345030 - this interface could be easily used for all kind things like your suggested email robot. (I personally wanna write an bot for automatically openening new bugs so we get notified if our source crawlers find a new version: http://sourcefarm.metux.de/)

This is basically possible now, with the inbound email interface, or with a third-party tool like scmbug.

(In reply to comment #43) > with the inbound email interface The whaa...? > or with a third-party tool like scmbug. I see some webpages discussing scmbug as an integrator of SCM and bug tracking, but how does this enable bugs to be closed via e-mail? If this is now possible, could you give a sequence of steps constituting an example? Otherwise, please consider reopening...

I am already doing this with the inbound email interface and subversion.I think it would be rather trivial to modify my script to work with CVS as this bug originally suggested, but I've never worked with CVS so I am not certain. Basically I have the post-commit-hook set up to perform some string manipulation on the commit log and then append the status and pipe it to email_in.pl I have it linked to from the bugzilla:addons wiki page (http://wiki.mozilla.org/Bugzilla:Addons) Full source of my script is here (I tried to comment it well): https://systems-300.stellarfinancial.com/svn_bz_email_in/svn_bz_append_email_in_mod With my script bugs can be closed by setting the correct parameters (@status, @resolution) in your commit dialog. I have another script that reads a pop3 mailbox and pipes the messages to email_in also. It is rather rudimentary (and contains the pop3 account password), so I will not post it here. Pretty much all it does is grab each message, delete it, and forward it to bugzilla by opening a filehandle to email_in.pl. Besides, that is Bug 94850; not this one.