Tracking bugs in Frameworks

[Christoph Feck]

My two cents from a bug triager's point of view:

1. General

* If new products/components are added, it would be nice if one of the 
maintainers is the default assignee, or - if the generic "kdelibs-
bugs" assignee stays - they are automatically added to the CC list. In 
case a component is unmaintained, the default assignee should reflect 
that fact.

2. Re: New bugs

* All bug reports are monitored, so the actual product/component does 
not matter from the perspective of the bug triaging team. I guess 
practice will show if/how we need to relayout later.
* My personal preference would be simply more components for kdelibs, 
where the splitting previously was not as fine grained as is now 
needed, e.g. for kdeui or kdecore.
* As David already suggested, a simple 5.0, 5.1 etc. version would 
clearly indicate that the user/developer tested the bug on the 
frameworks release.

3. Re: Old bugs

* Except bugs that are reported against now unmaintained features 
(KLineEdit etc.), existing bugs are very likely still valid for 
frameworks (the code, after all, just moved). To keep them into view 
for whoever maintains a framework, I highly suggest to not let them 
rot at any old place in bugzilla.
* If new products/components are created for frameworks, the bug 
triaging team will help moving the old reports.

Christoph Feck (kdepepo)
KDE Quality Team
openSUSE Review Team