This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex] 

Blip

Planning: Add support for bug trackers

Blip should know about the variuos bug trackers that are relevant to a given module. For a module in GNOME, for instance, this might include products from GNOME Bugzilla, Red Hat Bugzilla, Launchpad and others.

{i} I'm working on this -- FlorianLudwig

Interface

The two questions here are:

Comments

ShaunMcCance: 

We absolutely want the components for a given product,
along with the default assignees and QA contacts for those. Those can be linked to
the actual people in Blip , making their profile pages more useful. This would also
allow us to see what documents have the docs team as their default assignee. 

Do we actually want to store a list of all bugs in Blip ?  Or just bug counts and
links?  If we do bug counts (much easier, and less of a strain on the trackers we
talk to), we have to decide what combinations of fields are useful.

Do we do things per-branch or per-branchable?  How do we decide which bugs are
relevant to a given branch?  We do have the unstable and stable versions for a
branch in the database.

Can we find a way to do per-module and per-person activity graphs?  Activity
graphs are a staple of Blip 's interface, so it would be nice to have them.
But that requires getting full historical data, which might be asking too
much of the trackers we talk to.

Technical

Mapping

We need some mapping between application names in Blip and issue trackers, it might be possible

Collecting

Possible methods to collect the data from bug trackers:

2024-10-23 11:44