User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040401 Galeon/1.3.14 (Debian package 1.3.14a-1) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040401 Galeon/1.3.14 (Debian package 1.3.14a-1) An interface that facilitates integration of SCM systems with Bugzilla needs to be developed. <a href= "http://bugzilla.org/cgi-bin/mj_wwwusr?user=&passw=&list=developers&brief=on&func=archive-get-part&extra=200407/154">This</a> thread contains some discussion on this topic. One promising solution proposed by Christian Robottom Reis <kiko@async.com.br> is XML-RPC. Reproducible: Always Steps to Reproduce:

As a reference, this project attempts to create a web-service for MantisBT that can accept such integration actions. It may be worthwhile to examine: http://www.futureware.biz/mantisconnect/

Should be aware of the comments in bug 282493, comment 0 when this is implemented. Current Scmbug code has implemented some functions currently missing from Bugzilla, and these use SQL, so they might break in Bz 2.20. This increases the importance of an SCM integration interface. Still, it can wait since Scmbug works so far.

Reassigning bugs that I'm not actively working on to the default component owner in order to try to make some sanity out of my personal buglist. This doesn't mean the bug isn't being dealt with, just that I'm not the one doing it. If you are dealing with this bug, please assign it to yourself.

This would be a good place to start for what "plugins" would need.

I'm not sure how it's currently envisioned to provide this integration. I need a mechanism to extract from Bugzilla some bug metadata, or update bugs. In particular the API needed should provide at least the following: integration_connect_database integration_disconnect_database integration_add_comment integration_get_product_name integration_get_bug_owner integration_get_bug_status integration_bug_in_active_state integration_active_states_list integration_get_bug_subject integration_add_tag integration_tag_exists integration_delete_tag integration_vdd integration_vdd is currently a feature under development in Scmbug. The ultimate goal is to define a common query used to provide a version description document; that is a document detailing the bugs worked-on between releases, newly identified bugs, bugs marked as won't fix, etc. I'm attaching Bugzilla.pm.in v1.12 from the Scmbug codebase that demonstrates how these functions are currently implemented. This Scmbug backend currently connects directly to Bugzilla's DB and uses some functions from globals.pl. Currently, calls to is_version_up_to_2_16() and is_version_latest() attempt to implement schema-release-specific functionality. Ideally we'd like this logic to be in this interface and updated by Bugzilla developers when the schema does indeed change. The key point here is that it's time we all (all bug-trackers) identify the one, single common SCM integration interface needed to solve the "integration problem" once and for all (Scmbug's ultimate goal). This is *very much* open to discussion. Bugzilla gets to go first and define it. As for the mechanism (XML over RPC, direct db connections, etc.) are all welcome, as long as it's an approach that is guaranteed to work with all other bugtrackers. This may be too-agressive of a goal. E.g. Berkley-DB -based trackers with no DB daemon just can't accept direct db connections. Debian's file-based bugtracker also comes to mind. Hmmmm....

This is the existing Bugzilla bug-tracking backend in Scmbug. All integration_* functions in it demonstrate the functionality needed for generic SCM-to-bugtracking integration.

I've read some more on bug 289039. The plugin API envisioned by Bugzilla does not meet Scmbug's requirements. The issue of authentication remains open for SCM integration. Currently, Scmbug uses Bugzilla's localconfig and globals.pl to extract all the information needed. The DB username/password is retrieved Scmbug's config file (see init_specific in attachment #179905 [details]). In a sense, Scmbug assumes local DB access is available. The plugin API plan in bug #289039 assumes a user is already logged in and simply exercising a new custom feature loaded as a plugin. It does not permit one to interact with Bugzilla without logging in as the user. Scmbug for example must add comments coming in from several different SCM users impersonating those users. If direct access to the database is not available what's the recommended alternative ? Dave Swegen suggested in the past a general admin account for such a scenario. Just some thoughts.

As far as an SCMBug-type plugin goes, you're probably right that it doesn't fit the "plugins" that I had envisioned. Instead, I expect that SCMBug will be using the interface that we will work on in bug 224577. Ideally, SCMBug should never have to touch the database directly, but should do all its work through XML-RPC. Any bugtracker could implement XML-RPC, as long as they are a web-based bugtracker. *Thank you* for your post about what SCMBug needs, by the way. I was planning on sending you an email asking about exactly that. :-) If you could define the exact abstract data structure that you expect a "VDD" to be, that would be really helpful. A UML diagram, or a text-based description, or an implementation in any common Object-Oriented language (perl, Java, etc.) would all be OK. :-)

(In reply to comment #5) > The key point here is that it's time we all (all bug-trackers) identify the > one, single common SCM integration interface needed to solve the "integration > problem" once and for all (Scmbug's ultimate goal). This is *very much* open > to discussion. Bugzilla gets to go first and define it. By the way, I really like this idea. In fact, I'd like to take it even further and create a standardized XML-RPC bug-tracker interface. I'm going to talk it over with some folks, and then send out some emails and see if we can't get such a thing rolling. :-)

One thing I've wondered about, and have not spend enough time thinking on due to VDD being still in the works, is whether it's valuable to have in each bug an additional field called "Customer release notes" or something to that effect. The goal is to automatically produce a list of bugs that were worked on between releases. But perhaps it's better to only list meta-bugs for a higher-level customer-perspective, and both meta and actual bugs for a more detailed view. Arguably the bug summary should be used for that, but this field may summarize the problem at a lower-level developer level, rather than the higher-level customer response needed.

Discussion here so far seems to be about external systems calling into Bugzilla. However, I am dealing with a case where Bugzilla needs to make calls into an external system. In my case, changes to bug status need to be mirrored to an associated object in salesforce. My proposal is that instead of forcing people to poke into the underbelly of post_bug.cgi, risking their sanity and merge conflicts, a standardized set of hooks should be provided for various Bugzilla events. As a first step, the hooks can be for notification of the event having successfully taken place. Down the road, hooks for notification about an event that is about to take place could be provided, with a chance for the implementation to veto the proposed change. This would be useful even for internal Bugzilla customization. For instance, I needed to change the semantics of resolving a bug FIXED -- it could not be set unless a custom field version_fixed was also set at the same time. Conversely, if the bug changes status from RESOLVED FIXED to any other, this field has to be automatically cleared. You can see how this could be made a lot simpler with the hooks I describe. Are these ideas within the scope of this meta-bug, or should a new one be opened?

(In reply to comment #11) Your request is more like bug 298341.

The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).