|Anonymous | Login | Signup for a new account||2014-08-22 11:40 EDT|
|My View | View Issues | Change Log | Roadmap | Wiki | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0010543||mantisbt||relationships||public||2009-05-27 08:37||2010-02-09 04:40|
|Target Version||Fixed in Version|
|Summary||0010543: 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)|
|Attached Files|| snapshot1.png [^] (77,198 bytes) 2009-05-29 09:23
We'd be delighted to Create a new dokuwiki page, but currently can't (insufficient privileges ?)
In the meantime, here's 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 ?
|I haven't reviewed the drafted requirements yet, but I've created a wiki page for this issue. You should have enough access to edit it.|
|FYI, http://www.mantisbt.org/bugs/wiki.php?id=10543 [^] is ready for review... feel free to comment here or in the wiki page.|
|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 [^]|
oberger, sorry if I've 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? 
 http://git.mantisforge.org [^]
This is a great idea.
I've 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? I'm unsure on whether this new proposal would be best placed in a plugin because it sounds like it'll 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 don't 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? You'd 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 you'll 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 you're 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 it'd 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 don't 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 doesn't 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)? You'd need to check both open and closed bugs to see if bugs have both been resolved or reopened.
10. I think you'd 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 you're checking (to see if it has been resolved/reopened/etc). You'd 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?
|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.|
|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 [^]|
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.
|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 [^]|
|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|
| MantisBT 1.2.17 [^]
Copyright © 2000 - 2014 MantisBT Team
Time: 0.1342 seconds.|
memory usage: 3,083 KB