134294 - inter/cross-installation dependencies

Status: NEW

(Bugzilla :: Dependency Views, enhancement)

Description

[Myk Melez [:myk] [@mykmelez]]

[I thought I already filed this one, but apparently not.]

It should be possible for a bug report in one Bugzilla installation to depend on
a bug report in another Bugzilla installation.  This would make it possible, for
example, to track the inter-dependencies between different open-source projects
(f.e. Mozilla and RedHat or Mozilla and Bugzilla) and between open-source
projects and the commercial applications on which they are based (f.e. Mozilla
and Netscape).

Comment 1

[lchiang]

Not just dependendents.  Being able to mark a bug in one installation as a
duplicate of another bug in a second installation is also needed.

Comment 2

[Myk Melez [:myk] [@mykmelez]]

Cross-installation duplicates has been filed as bug 134761.  Moving this bug
report to the proper component and re-assigning.

Comment 3

[Dave Miller [:justdave]]

*** Bug 231432 has been marked as a duplicate of this bug. ***

Comment 4

[Dave Miller [:justdave]]

*** Bug 234106 has been marked as a duplicate of this bug. ***

Comment 5

[Dave Miller [:justdave]]

*** Bug 203628 has been marked as a duplicate of this bug. ***

Comment 6

[Dave Miller [:justdave]]

Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)

Comment 7

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 8

[timeless]

*** Bug 296884 has been marked as a duplicate of this bug. ***

Comment 9

[Dave Miller [:justdave]]

RedHat appears to have implemented this already on their Bugzilla.  Perhaps we
can get them to contribute it.

Comment 10

[Frédéric Buclin]

The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).

Comment 11

[Frédéric Buclin]

*** Bug 345959 has been marked as a duplicate of this bug. ***

Comment 12

[Max Kanat-Alexander]

Um, I have no idea how that security box got checked.

Comment 13

[Frédéric Buclin]

This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Comment 14

[Dave Miller [:justdave]]

*** Bug 358373 has been marked as a duplicate of this bug. ***

Comment 15

[GavinS]

[Related comment from Henry Story on developers@ mailing list]

Hello,

One problem with all bug tracking systems, is that they only allow you to state dependencies between bugs on one open source project. Problem is, that most open source project use libraries from other open source projects, which may themselves have bugs. So it can easily turn out that a bug in a project depends on a bug in another project. Since it is inconceivable that all open source projects use one big centralized bug database we need to do with the distributed system we have.

Luckily this is easy, since we have URLs to name things on the web.  So instead of identifying bugs with some primary key that is local to one database, we should be identifying them with URLs, and a good one to start with is the URLs of where they are published. So take the netbeans bug 51486 . It has URL

http://www.netbeans.org/issues/show_bug.cgi?id=51486#bug

So we should use that to describe it.

Now if we want to say something about it, that it has a property of some sort we need to identify the property. Since we need this to work on a global scale, we should name the property in a way that is clear globally, and the only way to do this is to use a URI. So let's create one for saying that a bug depends on another bug

http://baetle.googlecode.com/svn/ns/#depends_on

Ok, so far so good, so we just need to get the URL of the bug it depends on, I'll invent one here

http://issues.apache.org/bugzilla/show_bug.cgi?id=13099

Now we can write this out as a relation:

<http://www.netbeans.org/issues/show_bug.cgi?id=51486#bug> <http://baetle.googlecode.com/svn/ns/#depends_on> <http://issues.apache.org/bugzilla/show_bug.cgi?id=13099> .

or if we use namespaces

<http://www.netbeans.org/issues/show_bug.cgi?id=51486#bug>
      baetle:depends_on <http://issues.apache.org/bugzilla/show_bug.cgi?id=13099> .

Naming these relations is what the baetle prject is working on at
    http://baetle.googlecode.com/

It would be really great if we could get the involvement of the bugzilla community.

Henry

Comment 16

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.

Comment 18

[Frédéric Buclin]

dkl, want to attach here your implementation you use at RedHat? I could start from here. Else I will start from scratch.

Comment 19

[David Lawrence [:dkl]]

Attachment: Red Hat patch that adds external bug tracker references to 3.2 (v1)

Here is the patch we are currently using. It is used as an extension and is not part of the core Bugzilla code aside from some added Hooks we put in certain places to allow it to work.

I am not particularly happy with how it is implemented myself and would love to redo it if time allowed but for now it works. It uses a custom object instead of properly inheriting from Bugzilla::Object. It also uses custom tables left over from our 2.18 version so it would need to be reimplemented to use proper custom fields instead. Do with it as you like, but if it looks like crap, I won't be offended ;)

I would be able to help in the near future to reimplement this properly if some
one was willing to take on part of the work.

Here are the create statements for the tables we use with this code. They have not been added to Bugzilla::DB::Schema yet which is where they would need to go eventually.

CREATE TABLE `external_bugzilla` (
  `id` mediumint(9) NOT NULL auto_increment,
  `url` varchar(2000) NOT NULL,
  `description` varchar(2000) NOT NULL,
  `full_url` varchar(2000) default NULL,
  `is_bz` tinyint(1) default NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=38 DEFAULT CHARSET=utf8

CREATE TABLE `ext_bz_bug_map` (
  `bug_id` mediumint(9) NOT NULL,
  `ext_bz_id` mediumint(9) NOT NULL,
  `ext_bz_bug_id` mediumint(9) NOT NULL,
  UNIQUE KEY `ext_bz_bug_map_bug_id_idx` (`bug_id`,`ext_bz_id`,`ext_bz_bug_id`),
  KEY `ext_bz_bug_map_ext_bz_id_idx` (`ext_bz_id`),
  CONSTRAINT `ext_bz_bug_map_ibfk_1` FOREIGN KEY (`bug_id`) REFERENCES `bugs` (`bug_id`),
  CONSTRAINT `ext_bz_bug_map_ibfk_2` FOREIGN KEY (`ext_bz_id`) REFERENCES `bugs` (`bug_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 

Dave

Comment 20

[Max Kanat-Alexander]

I currently plan to implement bug 231429 instead of this, for all those who are interested.

Comment 21

[u336811]

FYI, for those curious about the feature in redhat's bugzilla, such bugs relations are found in the "External Bugs" block.

My 2 cents,

Comment 22

[Frédéric Buclin]

Bugzilla followed a much different way since last year, see bug 231429. This makes this bug a lower priority now, and will probably become an extension of the existing "see also" feature. Not something I'm focused on right now.

Comment 23

[Frédéric Buclin]

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.