Fwd: Tracking bugs in Frameworks

[David Edmundson]

On Sat, Dec 14, 2013 at 7:00 PM, Frank Reininghaus
<frank78ac at googlemail.com> wrote:
> 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")
>
That's a good option.

I think if we did that it would be a good idea to prefix the names
with a common element like
"frameworks-coreaddons" "frameworks-kio" etc.

Otherwise it will be difficult to find anything, especially as some of
the framework names are very generic.

> 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).

Making each repository a component was my original idea, but you are
right that it makes it harder to then add a finer grain of control.
I'm equally happy with your proposed plan.

>
> 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.
>
KIO is an interesting discussion; that old component is mostly the
IOslaves that used to be in kde-runtime, not the library itself. It
even also currently includes the audio slave which is in kdemultimedia
somewhere.

With frameworks some of the slaves moved to frameworks, but not all of them.

> 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.
>
++.

It's also an opportunity to subtly let all the old wishlist requests
and unreproducible crashes that have built up over all this time fade
away without causing too much drama. In a few years we can close
kdelibs for new requests and hide the product. It gives us a clean
slate to be better at triaging with.

> 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.
>
Thanks.