Fwd: Community patches and bugfixes to Qt?

[Thiago Macieira]

On Segunda 08 Setembro 2008 11:02:35 Philippe Fremy wrote:
> Thiago Macieira wrote:
> > We're exchanging our current Priority system for a User Pain-based
> > prioritisation of tasks. Instead of trying to guess a number from 1 to 5,
> > which varies a lot depending on the person doing the scheduling, we'd
> > instead have 3 evaluations:
> >
> >  * what kind of problem is it? (Minor annoyance to crashes and
> > regressions)
> >  * how many people are affected by it? (one one-license client to
> > thousands/millions of people)
> >  * how likely is it to hit this particular issue?
>
> I am a bit surprised that you don't take into account the "easyness" of
> the bug resolving. If you get a bug report from a high class contributor
> (let's say a core KDE developer), along with a patch that fixes the
> problem, it's worth applying it quickly.

This is about prioritisation. Sure, if it's a one-liner, it's probably easy to 
apply and close the task, then to move on to other important stuff. But it 
seldom is the case.

First of all, the "easiness" is very often deceiving. It looks easy, but when 
you look at it closely enough, it isn't. I'm hoping that, with the Qt 
autotests being made public, we'll get patches from KDE contributors that are 
tested too, and it's just a matter of proving that it isn't introducing 
regressions.

Even then, it's hard to be certain that regressions and other bugs aren't 
being introduced. So, I'd rather leave an easy patch for later when I have the 
time to fully understand it than to apply it and have things blowing up 
because of it.

One thing that I do is that I create a branch in Git for a task that I start 
looking into. If it's actually easy to fix, I'm done. If it proves to be more 
difficult than initially expected, I'll leave the branch there with the 
initial attempts at fixing. When I come back later, the code is still there.

But, no, "easiness of fixing" is definitely not a prioritisation criterion.

> But since KDE has millions of uses, it probably already gets a high
> priority based on your ranking, doesn't it ?

Yes, that's the point.

> The most important request I've seen so far, is that people that report
> a problem, along with deep analysis and patch to fix it should not be
> treated as the less knowledgable developers that report "damn it, it
> does not work". Is there anything going into that direction for the new
> system ?

No, it's going to be the same: the analysis has there. The Support Engineers 
are supposed to understand the problem and make an analysis of it, before it 
comes to the Software Engineers. If the reporter has done all of that already, 
the Support Engineer's job is made simpler, that's all.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080908/a0c1e5c9/attachment.sig>