431319 - Support for cross-site upstream tracking

Status: RESOLVED DUPLICATE of bug 123130

(Bugzilla :: WebService, enhancement)

Description

[Juha Tuomala]

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.5; x86_64; en_US) KHTML/3.5.9 (like Gecko)
Build Identifier: 


Opensource software projects typically utilize 
other opensource projects, called as 'upstream' like 
libraries and utility software components. In other
hand, project itself could be used as part of 
next project called 'downstream'.

Usually project community headcount grows when moving 
down the stream and so grows the activity.

Some issue may be caused by upstream and due 
the increased activity and other integrated 
projects in downstream, many issues are detected 
first time there instead of their actual origin.

Many projects use bugzilla or other similar system to
track their bugs and other issues. When studying the
community as whole, one can notice that actually 
'the stream' contains many bug-tracking instances.

Typically people tend to report bugs into that project 
where the bug was initially discovered, partly because
the project might be complex and integrate many 
upstream projects together and at the beginning it's 
hard say what actually causes the problem - integration
itself or some bug in the upstream.

Many projects have tens or hundred of thousands of bug
entries in their tracking systems and with all the
information in each bug, finding the related bugs and 
getting he overall picture of an issue is tedious
work and wastes valuable resources.

Time could be saved by creating a machine to machine 
communication between the bug tracker systems. As a 
result, each tracker would have some data about others
and able to add information to a bug entry:

- listing the whole stream: 
  * entry numbers in as urls linking to each project
  * status 
  * version
  * votes if used
- timewise composed comments in one page
- change notifications for downstreams (time to patch)
- oneway communication for org internal trackers

Some already provide XML-RPC interfaces through HTTP
http://www.bugzilla.org/features/#webservices

Red Hat's forked bugzilla already has fields for other 
bug tracker id numbers but it doesn't really utilize 
the information more than rendering a passive urls 
to an entry page.

Building a such network would probably rise questions
too, like:

- how the user id-mapping should be done?
- product and component names may differ in trackers, 
  would that matter? handled with manual mapping?
- should the RPC API be unified between tracker implementations?
- if the API is unified, who would maintain it?
- should changes be triggered or polled?

Even the would not be an cross-software API, many
projects use bugzilla and they already would hugely 
benefit from this kind of feature.


Related proposals (not exact duplicates):
  http://bugzilla.mozilla.org/show_bug.cgi?id=285364
  http://bugzilla.mozilla.org/show_bug.cgi?id=134294
  http://bugzilla.mozilla.org/show_bug.cgi?id=134761


Example of one stream of project dependencis:

  http://www.gnu.org/software/libc/       - bugzilla
    http://libwbxml.aymerick.com/         - trac
      http://www.opensync.org/            - trac
        http://www.kde.org/               - bugzilla
          http://www.debian.org/          - in-house perl
            http://www.kubuntu.org/       - launchpad
          http://www.fedoraproject.org/   - forked bugzilla


Reproducible: Always

Comment 2

[Juha Tuomala]

bug #134294 is not an exact duplicate.

> - listing the whole stream: 
>  * entry numbers in as urls linking to each project
>   * status 
>  * version
>  * votes if used

Something like dependency tree view with labels what project
the entry is in the stream (like KDE).

> - timewise composed comments in one page

mix all comments into same page on one site. Those could
be probably read at the same time when show_bug is run 
in server side or then done in browser with AJAX directly 
and fetching the comments from different projects using 
XML-RPC.

> - change notifications for downstreams (time to patch)

kde bug changes state --> make a comment automatically 
into fedora too --> it sends emails to fedora maintainers.

> - oneway communication for org internal trackers

many companies use bugzilla internally, this feature should not
talk both ways in such case.

My point is, that we already get notifications by creating accounts
into all stages in project and get emailed when something changes.

What I'm talking about is collecting the information into one running
process (server side or client javascript) visualizing it into one 
page. Dependencies page does it for summaries now but not for comments
which are the most important.

That kind of merging could be also useful when labeling bugs as duplicates
as all of them have tiny bits of information that should be visible in 
one final page (perhaps checking copied comments with radiobox when 
closing as duplicate).

Comment 4

[Frédéric Buclin]

Do not reopen the bug without explaining why you think it should be reopened.

Comment 5

[Juha Tuomala]

> Do not reopen the bug without explaining why you think it should be reopened.

But you can close as DUPLICATE without writing a single comment why it's duplicate.

Comment 6

[Frédéric Buclin]

(In reply to comment #5)
> But you can close as DUPLICATE without writing a single comment why it's
> duplicate.

If you read the bug I point yours to, and other bugs blocking it, you will notice it's a duplicate. It doesn't need more explanations. Now leave this bug as duplicate, please.