Tracking bugs in Frameworks

Frank Reininghaus frank78ac at googlemail.com
Sat Dec 14 18:00:04 UTC 2013


Hi,

2013/12/14 David Edmundson:
> As we gear Frameworks up for release we need a way to track bugs that
> exist in the new Frameworks.
>
> We have two options; either we copy all the bugs in kdelibs, triaging,
> testing and moving to the right new component or we start fresh.
>
> There are approximate 1400 open bugs marked against in kdelibs; many
> of these I think are invalid duplicates. It's not an impossible amount
> to triage, but it would still be a large amount of work to test and
> then either move or resolve them.
>
> Given we still plan to support bugs in kdelibs officially for a while
> yet and I personally think it would be easiest for everyone to make a
> new bugzilla product called Frameworks and add newly found Frameworks
> bugs there.

an alternative would be to let every "Framework" have its own product.
Some parts of kdelibs have had their own products for quite some time
(e.g., kio and kfile), whereas others are tracked at the generic
product "kdelibs", or at yet other products (like "konqeuror/khtml")

IMHO, it would be much more transparent for bug triagers, developers,
and users if there was a nice 1:1 correspondence between the split
repositories/frameworks and the bugzilla products. One could argue
that each repository could also be a "component" of the product
"Frameworks", but this would remove the option to define more
fine-grained "components" for a particular framework (e.g., the
current product "kfile" has some different components for different
parts of that library).

Maybe one could create a bugzilla product for each "Framework" (unless
the product exists already, like kio). One could set up a version
"frameworks" in each of them as long as the frameworks don't have
proper versions yet.

About the existing kdelibs bugs: I think they should just remain
assigned to "kdelibs" as long as 4.x is supported. If any of these
bugs is fixed, one just has to remember to forward-port the fix to the
split frameworks repositories.

Finally, I think it's crucial to consider the opinion of the people
who do the most work at bugs.kde.org. I've CC'ed some of them because
I'm not sure if they follow this mailing list.

Best regards,
Frank


More information about the Kde-frameworks-devel mailing list