254400 - Provide an interface for SCM integration

Status: NEW

(Bugzilla :: Bugzilla-General, enhancement, P3)

Description

[Kristis Makris]

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 <[e-mail]> is XML-RPC.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Kristis Makris]

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/

Comment 2

[Kristis Makris]

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.

Comment 3

[Dave Miller [:justdave]]

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.

Comment 4

[Max Kanat-Alexander]

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

Comment 5

[Kristis Makris]

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....

Comment 6

[Kristis Makris]

Attachment: v1.12 of Bugzilla.pm.in from Scmbug.

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.

Comment 7

[Kristis Makris]

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.

Comment 8

[Max Kanat-Alexander]

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. :-)

Comment 9

[Max Kanat-Alexander]

(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. :-)

Comment 10

[Kristis Makris]

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.

Comment 11

[Anton Ivanov]

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?

Comment 12

[Max Kanat-Alexander]

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

Comment 13

[Frédéric Buclin]

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).