Thoughts about a better Quality Management process for Plasma

[David Edmundson]

On Thu, Jan 17, 2013 at 11:51 AM, Martin Gräßlin <mgraesslin at kde.org> wrote:

> On Thursday 17 January 2013 11:22:04 David Edmundson wrote:
> > This morning I spent an hour going through the list of "general", I
> > found a few problems.
> >
> > There were several bugs I looked at where the relevant component
> > didn't exist (webslice plasmoid, timer plasmoid).
> > All plasmoids should have a component, it's much easier to manage lots
> > of small lists than one big one, especially for delegating. I created
> > components for the items I found (hope that's OK), and will continue
> > to do so. If anyone else finds one of these, ping someone with
> > bugzilla superpowers (like me)
> I think that's the way to go. As I wrote: there should be a component for
> it.
> >
> > There are a lot of crashes filed against general, looking at the
> > backtrace it's impossible to see who's at fault. The backtrace only
> > shows some timer firing, or a python binding call or something generic
> > - it's impossible to tell what's at fault. I have no idea how we can
> > fix this.
> For those crashes the most important one is whether there is a way to
> reproduce them. If not -> garbage. No use in a crash report where we don't
> know what caused it.
> >
> > Some bugs weren't even against plasma (as devs know it). As we use the
> > phrase "plasma workspaces" I guess it's natural for bugs to end up
> > here which are totally generic. I found bugs on kwin, dolphin, and
> > other KDE things. I don't think there's really a fix for this.
> ah that was the reason for the bug you moved to us :-)
>
> It's a common thing to happen. In KWin we get bugs for:
> * Plasma
> * X
> * screen locker (that's very recent due to the original plans to move it
> inside KWin)
>
> So I think it will always happen that bugs are wrongly reported. Actually
> that's what I would love to have the bug squad for. No need to have devs
> move
> it around.
> >
> > There's a lot of wishlists.
> > I found these very hard to triage because I can't say on someone
> > else's project saying "we're never doing this, wontfix", which I would
> > do on my projects (maybe slightly more politely). I imagine many
> > others are in the same position, how can we manage this?
> get a proper policy, like wishes only on brainstorm. I just find
> bugtrackers
> unsuited for wishes.
>
> I went through plasma - general again today and on top of the usual bits
of triage I made a list of all requests for new plasmoids and new
wallpapers.

I want to triage these out of general and put them into a new component
"plasma-requests", or we can go with Martin's suggestion for all feature
requests and just close them.

I don't generally agree with the concept of close all wishlists, however
new plasmoids are the most extreme case of wishlists and I think in this
case it makes sense.

If we have a ruling, I'l update all of them.

List of new plasmoids:

163593

171737

186974

187562

199001

203313

208742

219631

229768

259598

314223

315352

157048

169457




> Thanks for looking into it :-)
>
> --
> Martin Gräßlin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130218/ec8a41e9/attachment.html>