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.
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
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.
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.
*** Bug 431319 has been marked as a duplicate of this bug. ***
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
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.
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.