View Issue Details

IDProjectCategoryView StatusLast Update
0010543mantisbtrelationshipspublic2010-02-09 04:40
Reporteroberger 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status acknowledgedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0010543: Proposal: Relationships to external bugs in remote bugtrackers
Description

We propose to add to mantis a plug-in which could help managing relationships between bugs in a Mantis instance, and external bugs in remote bugtrackers (not necessarily mantis)

Additional Information

Will be described in the wiki (link to be added later)

Tagsbts_link

Relationships

related to 0009940 closedvboctor Create on Integration Plugin for Launchpad 

Activities

oberger

oberger

2009-05-27 08:42

reporter   ~0021936

Wed be delighted to Create a new dokuwiki page, but currently cant (insufficient privileges ?)

In the meantime, heres what was drafted internally : https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/MantisMonitoringRemoteBugs

Should someone please copy that to http://www.mantisbt.org/bugs/wiki.php?id=10543 so that all can amend the proposal ?

vboctor

vboctor

2009-05-27 12:54

manager   ~0021943

I havent reviewed the drafted requirements yet, but Ive created a wiki page for this issue. You should have enough access to edit it.

oberger

oberger

2009-05-27 13:40

reporter   ~0021944

Thanks Victor.

oberger

oberger

2009-05-28 09:04

reporter   ~0021956

FYI, http://www.mantisbt.org/bugs/wiki.php?id=10543 is ready for review... feel free to comment here or in the wiki page.

oberger

oberger

2009-05-28 09:06

reporter   ~0021957

See also some related discussions initially sent on the ML : http://sourceforge.net/mailarchive/message.php?msg_name=1242031642.10766.1.camel%40erty.int-evry.fr

2009-05-29 09:23

 

snapshot1.png (77,198 bytes)
snapshot1.png (77,198 bytes)
jreese

jreese

2009-06-10 10:17

reporter   ~0022069

oberger, sorry if Ive missed this, but is the source code for the plugin (or whatever you used to make your screenshot) publicly available? If so, where at, and would you considering making it available on MantisForge? [1]

Cheers

[1] http://git.mantisforge.org

dhx

dhx

2009-06-10 10:53

reporter   ~0022071

This is a great idea.

Ive read through your proposal on the Wiki and have some comments and discussion to add.

  1. It sounds like this feature is going to require so much modification to the current relationships feature built into Mantis, that it is essentially a rewrite? Im unsure on whether this new proposal would be best placed in a plugin because it sounds like itll still need some heavy modifications to the Mantis core. And there is ongoing discussion at the moment about where plugins are hosted, who maintains them, etc. IMO it is best if the Mantis project took on some key plugins as official plugins to help guarantee that they dont die or become unmaintained, as is often the case with plugins in other applications.

  2. I think the only new relationships needed are upstream bug and downstream bug or something along those lines. As you stated, it is best if the existing related to, child of and parent of relationships also work remotely.

  3. What do you do if a ticket has a relationship to each of two different upstream bugs on different trackers? Youd need to wait for all upstream bugs to report the same status before automatically closing the local Mantis ticket. This also poses the problem of needing the user to specify the relation between statuses on a remote tracker, and the local Mantis tracker. Essentially youll need to have user-adjustable thresholds for each upstream tracker linked to the local Mantis install to define what the closed/resolved/open statuses are on the remote trackers.

  4. From (3) I propose that it is necessary for this new feature to have a database table that stores configuration data on each remote tracker linked to the current Mantis install. The user can then specify the method used for accessing the remote bug tracker (SOAP, etc) where a choice exists, the URL, username, password, whether to use TLS, the remote status that corresponds to a closed/resolved/etc ticket, etc.

  5. Because (4) is a lot of work for users who just want to report a bug, should the new feature youre developing try to figure things out by itself (assuming default settings on the remote tracker)? At the least it should simply not poll or push updates to the remote tracker unless the remote bug tracker has been properly configured. Maybe itd be a good idea to include some popular defaults as part of the feature (Ubuntu, Debian, Gentoo, etc) to give users a quick head start (and some examples to work off)?

  6. Should this new feature push changes to a remote tracker, or pull changes... or both? This sounds like something that needs to be configured on a per-remote-tracker basis in case your remote tracker happens to be a similar Mantis install. You dont want tracker 1 to push changes to tracker 2 while tracker 2 concurrently duplicates that effort by pulling the changes from tracker 1.

  7. Custom fields - how to synchronise or use custom fields when the remote trackers may not support the custom field being used locally?

  8. I disagree with the proposal to log agent events when the remote bug tracker is polled. This information should already be viewable on the remote bug tracker if the user clicks the link to view the remote bug report. There is no need to duplicate this existing information.

  9. Regarding the whole concept of polling other tracker - doing this on a cycle sounds like bad form to me. It simply doesnt scale, and will always be a long way off being real time. Imagine having 1000 bugs on your local install of Mantis and each of them is linked to a remote bug. Do you really want to make 1000 remote requests to those trackers every hour (or whatever your interval is)? Youd need to check both open and closed bugs to see if bugs have both been resolved or reopened.

  10. I think youd need to check the relationships of remote bugs before showing a local Mantis bug to the user. This takes time... maybe 2-3 seconds per remote bug youre checking (to see if it has been resolved/reopened/etc). Youd also need to have a minimum time between checks to prevent flooding and DoS attacks on smaller trackers. If you have a bug on your local install of Mantis that tracks a security flaw, it will most likely be linked to 0000007:0000015-20 remote bug trackers for all the main Linux distributions that create a new security ticket for each CVE/etc number. Can you check the status of all 15-20 remote bugs asynchronously when viewing the local bug on Mantis? Or do you have to wait while all 20 bugs are checked in a serial blocking way?
dhx

dhx

2009-06-10 10:55

reporter   ~0022072

Also in terms of architecture, you should check out the source-integration plugin at git.mantisforge.org for a good example of how to use plugins. I was thinking that each remote bug tracker type would need its own plugin (mantis, launchpad, bugzilla, trac, etc) to handle the communication and interface with the remote tracker.

mdhar

mdhar

2009-07-03 10:49

reporter   ~0022365

jreese, please find here the link to our on-going work: http://git.mantisforge.org/w/mantisbt/helios.git?a=shortlog;h=refs/heads/ext_plugin

mdhar

mdhar

2009-07-03 12:06

reporter   ~0022366

dhx, thanks for your comments and suggestions.

Currently, we are trying to keep the external relationship similar to, but separate from, the in-built mantis relationships. However, it is true that making it viewable along with the other bug information, requires a certain amount of modification. We await the response of others in the mantis community to see their view. Our work has been added to the mantis git repository and the link provided in my previous post.

The initial version of our feature will have a link to the external bug whose status would be tracked by an external agent, bts-link, in this case. There would be some functionality provided like, automatic closing of a local bug when its corresponding external bugs are closed. We are not looking at customised settings and behaviour for each remote tracker for the first version.

Nothing will be pushed to remote trackers. Bts-link, running on the local mantis, will poll the remote trackers and update the changes in the local one.

Regarding logging agent events, we will look into whether to keep previous change information or not. Like you said, as the information is already available, we might drop the idea.

As for the polling of remote bugtrackers, things have to be finalised still. There might be a special status for bugs tracking security flaws, which will have their corresponding external bugs tracked asynchronously.

oberger

oberger

2009-08-04 11:19

reporter   ~0022658

FYI, a similar feature (although less advanced ;) has been implemented in bugzilla 3.4, apparently : http://www.bugzilla.org/releases/3.4/release-notes.html#v34_feat_see

Issue History

Date Modified Username Field Change
2009-05-27 08:37 oberger New Issue
2009-05-27 08:42 oberger Note Added: 0021936
2009-05-27 08:53 jreese Relationship added related to 0009940
2009-05-27 12:54 vboctor Note Added: 0021943
2009-05-27 13:40 oberger Note Added: 0021944
2009-05-28 09:04 oberger Note Added: 0021956
2009-05-28 09:06 oberger Note Added: 0021957
2009-05-28 09:06 oberger Tag Attached: bts_link
2009-05-29 09:23 mdhar File Added: snapshot1.png
2009-06-10 10:17 jreese Note Added: 0022069
2009-06-10 10:53 dhx Note Added: 0022071
2009-06-10 10:55 dhx Note Added: 0022072
2009-07-03 10:49 mdhar Note Added: 0022365
2009-07-03 12:06 mdhar Note Added: 0022366
2009-07-03 14:02 vboctor Status new => acknowledged
2009-08-04 11:19 oberger Note Added: 0022658