Open Bug 134294 Opened 18 years ago Updated 5 years ago
[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).
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.
Cross-installation duplicates has been filed as bug 134761. Moving this bug report to the proper component and re-assigning.
Assignee: justdave → myk
Component: Bugzilla-General → Creating/Changing Bugs
Priority: P4 → P2
Target Milestone: Future → Bugzilla 2.18
*** Bug 231432 has been marked as a duplicate of this bug. ***
*** Bug 234106 has been marked as a duplicate of this bug. ***
*** Bug 203628 has been marked as a duplicate of this bug. ***
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)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
*** Bug 296884 has been marked as a duplicate of this bug. ***
RedHat appears to have implemented this already on their Bugzilla. Perhaps we can get them to contribute it.
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).
Target Milestone: Bugzilla 2.22 → ---
Assignee: myk → import-export
Component: Creating/Changing Bugs → Bug Import/Export & Moving
Priority: P2 → --
Target Milestone: --- → Bugzilla 3.0
*** Bug 345959 has been marked as a duplicate of this bug. ***
Target Milestone: Bugzilla 3.0 → Bugzilla 2.24
Um, I have no idea how that security box got checked.
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".
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
*** Bug 358373 has been marked as a duplicate of this bug. ***
[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
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.
Target Milestone: Bugzilla 3.2 → ---
Assignee: import-export → dependency.views
Component: Bug Import/Export & Moving → Dependency Views
Priority: -- → P1
Whiteboard: [roadmap: 4.0]
dkl, want to attach here your implementation you use at RedHat? I could start from here. Else I will start from scratch.
Assignee: dependency.views → LpSolit
Status: NEW → ASSIGNED
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
I currently plan to implement bug 231429 instead of this, for all those who are interested.
FYI, for those curious about the feature in redhat's bugzilla, such bugs relations are found in the "External Bugs" block. My 2 cents,
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.
Assignee: LpSolit → dependency.views
Status: ASSIGNED → NEW
Priority: P1 → --
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.
Target Milestone: Bugzilla 4.4 → ---
You need to log in before you can comment on or make changes to this bug.