Last Comment Bug 123130 - Inter-Bugzilla Integration Capabilities (Dependencies, Moving, etc.)
: Inter-Bugzilla Integration Capabilities (Dependencies, Moving, etc.)
Status: NEW
[roadmap: 4.0]
: meta
Product: Bugzilla
Classification: Server Software
Component: Bugzilla-General (show other bugs)
: unspecified
: All All
: P1 enhancement with 6 votes (vote)
: ---
Assigned To: Tiago Mello [:timello]
: default-qa
:
Mentors:
: 107686 275228 356969 431319 (view as bug list)
Depends on: 127871 134294 134761 bz-seealso 719725 173330 webservices
Blocks: 127875 127876 128613 380493
  Show dependency treegraph
 
Reported: 2002-02-02 07:15 PST by xyzzy
Modified: 2013-08-01 10:28 PDT (History)
29 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description xyzzy 2002-02-02 07:15:48 PST
From my wishlist to yours:

It would be really cool if Bugzilla was "aware" of other installations of
Bugzilla at remote locations.  This would be really convenient for locating and
reporting bugs in the other installations, especially those that our products
depend upon.  It would help automate "moving" bugs to other installations too.

The chosen sites would be picked by the administrator, but the actual remote
product info should probably be concealed from the user, they will see that info
after we redirect them there, and would only add clutter locally.

Bug reporting would follow local processes of reporting and processing, and
perhaps the user should be made aware of any changes in reporting procedure if
we redirect.  Moved bugs would need to be accepted, in order to enable the
remote site to adapt the bug to its process.

It would be really cool if we could make interaction with private and public
installations seamless for users with access to both, but I can't think of a way
to do this without breaking the experience of those that don't have a remote
account or are outside a potential firewall.

This request would also open up the possibility for external dependencies, and
probably much, much more that I am ignoring at present.  Feel free to enlighten me.
Comment 1 Myk Melez [:myk] [@mykmelez] 2002-02-27 11:23:28 PST
Taking, although the specifics of this feature request are a bit vague, since
I'm planning to work on this kind of stuff.
Comment 2 xyzzy 2002-02-27 16:51:17 PST
Myk,

It is a bit vague, but I'm glad you've decided to work on it!  I will try to
clarify anything I can, please ask.  My vision centers around two scenarios, the
public-private interaction like b.m.o and bugscape, and potential public-public
interaction between related open-source projects, like b.m.o and Redhat, or
upstream product dependencies, like the Bugzilla product and Template Toolkit.

I would like to make these interactions as clean as possible, so that browsing
from one to another is simple.  Ideally, one could write a client app that would
interact with all Bugzilla installations, filing bugs and reporting on status in
unrelated products.  Maybe I should turn this into a tracking bug and file some
dependencies?
Comment 3 Myk Melez [:myk] [@mykmelez] 2002-02-28 16:20:18 PST
Yes, please do add dependencies to this bug so I can see what you think needs to
be done for this.
Comment 4 Dennis Haney 2003-01-28 14:12:10 PST
*** Bug 107686 has been marked as a duplicate of this bug. ***
Comment 5 Dave Miller [:justdave] (justdave@bugzilla.org) 2004-12-18 18:39:32 PST
*** Bug 275228 has been marked as a duplicate of this bug. ***
Comment 6 Zibi Braniecki [:gandalf][:zibi] 2004-12-18 18:45:40 PST
In bug 275228 Comment 1 I described a little bit some ideas about handling
accounts between bugzillas.
Comment 7 Eldo Varghese 2006-02-25 12:38:07 PST
if anyone wants to see a closed source implementation of this take a look at the ubuntu malone: launchpad.net/malone
Comment 8 Max Kanat-Alexander 2006-02-25 13:39:16 PST
I assume that nobody is actually working on this, since we haven't discussed it much ever. If I'm wrong, feel free to take it back.
Comment 9 jessn 2006-10-18 00:31:39 PDT
Integration / references to other systems as described in bugs 356969 would be nice as well. This will make bugzilla capable "interact" with others systems and migration between those will be easier.
Comment 10 jessn 2006-10-18 00:35:27 PDT
*** Bug 356969 has been marked as a duplicate of this bug. ***
Comment 11 jessn 2006-10-18 00:36:41 PDT
(In reply to comment #9)
> Integration / references to other systems as described in bugs 356969 would be
> nice as well. This will make bugzilla capable "interact" with others systems
> and migration between those will be easier.

Bug #356969 
Comment 12 Stephanie Daugherty [:sdaugherty] 2007-05-12 02:50:26 PDT
I don't think bug 356969 was really a duplicate, since it just called for an interface without specifying that the source/destination had to be another Bugzilla, but in any case, it could have been spelled out more clearly. I filed bug 380493, which is what I *think* 356969 was trying to say, but I don't want to risk expanding the scope of that bug past what was intended, so it's a new bug.

It's a little more ambitious of a project, but there's some potential for code reuse between it and this bug...
Comment 13 Frédéric Buclin 2007-08-07 14:33:18 PDT
Time flies and we freeze again in one month, meaning that we won't have time to implement this feature for 3.2. But at our Bugzilla meeting we had today, we decided that this implementation would worth bumping the Bugzilla version to 4.0. So this bug is officially the very first one targetted to Bugzilla 4.0 and we won't release Bugzilla 4.0 without it implemented.
Comment 14 Frédéric Buclin 2008-04-29 10:18:27 PDT
*** Bug 431319 has been marked as a duplicate of this bug. ***
Comment 15 Frédéric Buclin 2008-10-21 07:35:59 PDT
*** Bug 431319 has been marked as a duplicate of this bug. ***
Comment 16 Frédéric Buclin 2008-10-21 07:49:07 PDT
*** Bug 431319 has been marked as a duplicate of this bug. ***
Comment 17 alexander.adolf 2008-12-15 01:59:42 PST
I am also eagerly waiting for this feature. We've got a couple of sites round the globe and due to network latencies have to have local Bugzillas. Having some interconnetcion between them to be able to add cross-site dependencies would be great. In our corporate environment single sign-on access woudl also be important.

Furthering this, the Subversion scheme of putting links into the configuration for certain products or components (effectively redirecting to remote Bugzillas for these) comes ot my mind. This would enable me to provide a uniform view onto the Bugzilla for all users. I believe this would also be handy for the public/private use-case outlined by xyzzy?
Comment 18 Max Kanat-Alexander 2010-09-03 19:26:46 PDT
Timello has agreed to take over this feature, and he asked me to give some of my thoughts on the general direction it should take, here.

First, off, let's really finish bug 231429. I want to see the See Also field work really well, in a way that people *like* and is convenient for them. I want it to be really useful, and also very extendable. I want See Also fields on different Bugzillas to be able to update each other, also. I have a lot of thoughts on See Also that I'll put into the relevant bugs.

Then, once that's done, I want to see the ability to move bugs between multiple different installations, bug 127871. It should be done via WebServices.

Also, Christian is working on a patch for bug 537749, the "Related Bugs" feature. Once that's done, I'd like to merge See Also and Related Bugs, so that any "Related Bugs" field can point to a bug in a different installation.

Another thing I'd like to see is comment synchronization between different trackers. Launchpad can already do this, but there are situations in which it would be nice to be able to pull, inline, all of the comments from related bugs in other trackers. We wouldn't have to physically add them to the database, perhaps, but we could just pull them via WebServices and add them to the bug (perhaps optionally).

Finally, at some point it would be great to have this work with every popular tracker, not just Bugzilla. (That is, Bugzilla should be able to move bugs into any tracker, etc.)
Comment 19 Matěj Cepl 2010-11-01 04:16:29 PDT
I would have one more request (I am not sure whether I should file a new bug or there is a one already existing ... I cannot find one though) which I described here http://article.gmane.org/gmane.linux.redhat.fedora.devel/79936/ in more detail.

Basically what I would like to have (as a downstream bug triager dealing with many bugs which are sent to upstream projects; BTW, quite often to bugzilla.mozilla.org) is a possibility to have inter-bugzilla COMMUNICATION, so that downstream reporter wouldn't have to make yet another account on the upstream bugzilla (people are really reluctant to do so) and all needinfos etc. would be sent to him through HIS bugzilla (after all, he is user of Fedora/Ubuntu/OpenSuSE, he filed his bug there, why should he care about b.m.o)?

I guess, OpenID and/or OAuth could be part of the solution, but I guess it is not the whole thing IMHO.
Comment 20 Max Kanat-Alexander 2011-03-03 07:51:55 PST
(In reply to comment #19)
> I would have one more request (I am not sure whether I should file a new bug or
> there is a one already existing ... I cannot find one though) which I described
> here http://article.gmane.org/gmane.linux.redhat.fedora.devel/79936/ in more
> detail.

  Hmm. File a bug for "this bugzilla should be able to update users about changes in a remote bugzilla". It would actually be several different features, but that would be the general "umbrella" summary.
Comment 21 Matěj Cepl 2012-01-20 00:22:59 PST
(In reply to Max Kanat-Alexander from comment #20)
>   Hmm. File a bug for "this bugzilla should be able to update users about
> changes in a remote bugzilla". It would actually be several different
> features, but that would be the general "umbrella" summary.

bug 719725
Comment 22 Frédéric Buclin 2012-08-25 02:00:15 PDT
We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.

Note You need to log in before you can comment on or make changes to this bug.