Summary of bugtracker situation discussion

Àlex Fiestas afiestas at kde.org
Sun Jan 19 13:25:26 UTC 2014


On Sunday 19 January 2014 12:39:03 David Edmundson wrote:
> On Sun, Jan 19, 2014 at 8:48 AM, Martin Graesslin <mgraesslin at kde.org> 
wrote:
> > Hi Christoph,
> > 
> > during the Plasma sprint we discussed the bug situation and want to get
> > your feedback on our ideas. In case there is a team mailing list please
> > feel free to forward the mail. Our goal is to improve the situation with
> > Plasma 2. We have to admit that we have failed with the current bugzilla
> > situation and that we are probably not able to clean that up.
> > 
> > One of the problems we identified is that we just get way too many bug
> > reports to be able to handle. All bugs and all wishlist items end up in
> > the product plasma. That's just too much. Our idea here is to focus,
> > focus and focus. The Plasma team only dedicates itself to maintain the
> > "essential" parts (to be defined, e.g. taskmanager, digital clock,
> > launcher...) everything else (e.g. comic strip) should not end up in the
> > product plasma but in a different product or in many products. This could
> > depend on what the maintainers of the products want.
> > 
> > With that change in place we should be able to reduce the number of
> > incoming bug reports to a level that we could start caring. Our idea in
> > that regard is that each of our essential components has a maintainer who
> > looks into the bug reports.
> > 
> > Another idea is also to reduce the number of incoming crashers. One thing
> > we had seen in the past is that 3rd party applets easily crash the system
> > (hello python). We don't care about those. We could implement this by a
> > system like what Linux kernel uses: 3rd party module means the system is
> > tainted and the crash report gets discarded. That might filter out some
> > legit crashes, but those will be reported again.
> > 
> > On the field of wishlist items we thought about not accepting any ideas
> > for
> > "new plasmoids" any more. We only care about the essential modules and
> > thus
> > are not interested in developing new non-essential plasmoids. So all
> > incoming wishlist items for new plasmoids  could be just closed with a
> > standardized message.
> > 
> > Last but not least we also had some ideas for the current situation. We
> > don't think it's possible to ask the maintainers of essential modules to
> > go through the Plasma 1 bugs and check whether they are still valid.
> > Given the terrible state we would scare anybody away from becoming
> > maintainer. So we need to improve that. One idea is to mass close
> > everything which had been reported against a version before 4.11. 4.11 is
> > our long-term release and everything else is unmaintained. This could
> > cause some uncomfortable situations with our users but if we draft a well
> > written message our users might be able to understand it. The second idea
> > in that area is that we only care about the Plasmoids written in QML from
> > the Plasma 1 times.
> 
> I would prefer to consider it as; there are too many reports for us to
> triage, so we will send the reporter message them a message asking
> them to triage their own bug. They should test if it still applies in
> the new Plasma and reopen on the new product accordingly. Till then we
> will close it.
> 
> In practice it amounts to the same thing, but it comes across better.
Exactly my thoughts.



More information about the Plasma-devel mailing list