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.
Taking, although the specifics of this feature request are a bit vague, since I'm planning to work on this kind of stuff.
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?
Yes, please do add dependencies to this bug so I can see what you think needs to be done for this.
*** Bug 107686 has been marked as a duplicate of this bug. ***
*** Bug 275228 has been marked as a duplicate of this bug. ***
In bug 275228 Comment 1 I described a little bit some ideas about handling accounts between bugzillas.
if anyone wants to see a closed source implementation of this take a look at the ubuntu malone: launchpad.net/malone
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.
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 has been marked as a duplicate of this bug. ***
(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
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...
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.
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?
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.)
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.
(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.
(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
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.