Fwd: Community patches and bugfixes to Qt?

[Thiago Macieira]

Girish Ramakrishnan wrote:
>Unless I misunderstood what you are saying, these issues are already
>covered. Trolltech has a copyright assignment form that one can fill and
>send in patches. I have personally done this; it's a bit tedious but
>possible :).

It's there and I've used it too.

>1. Task tracker needs a revamp - It needs a voting system, a commenting
>mechanism, to upload user patches/attachments. More importantly, I need
>a way to get notifications when the bug changes state.

Noted, but that's obviously not easy to do.

>2. A clear explanation for priorities given to bugs. For example, why is
>219293 P4? I would have thought since it is a regression it would be
>fixed asap (atleast, I think I reported it as a regression; the bug
>report form doesn't seem to have mailed me back the bug I filed). The
>point being, I would like to know why and it takes effort to find out
>(it is surely possible to just ping Thiago and find out, of course).
>Instead, provide the information upfront.

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?

With that, the task is given a score number, which will be where we base 
our prioritisation on. The values assigned by the scheduling will be made 
public, so the task reporter can contest them with actual data, instead 
of trying to get his way by bumping the priority.

We're implementing this right now. The changes to Hooligan (the internal 
rich-client program) have been made and are being tested.

>3. How are contributors acknowledged? Something as trivial as mentioning
>it in the ChangeLog will be enough for me.

Good point.

We leave the remark right now in the commit message, but those aren't 
published...

>4. Without opening up Qt's unit tests completely, it seems to me that
>every user patch will require lots of boring effort for the integrator.
>A patch without unit tests has limited value.

Unit tests are coming. Their release has been delayed by other facts. 
Before we release them, we have to:

 * add copyright headers to them
 * clean up references to internal structures

For example, the network tests make no sense outside our firewalls because 
the machine serving the requests won't be accessible. We have someone 
working on installing a Linux server on a VMWare image to serve those 
requests. This image will be made available somehow for testers, so that 
most network tests can be made. (for example, the tests against a 
Microsoft IIS server will be broken)

There are other fixes required and I only know the networking ones. Sure, 
we'd receive lots of help from test users when we release them, but we 
have to do some cleanup first.

[Anecdote: some tests started breaking when switching to the Nokia network 
because they assumed that "foo" would be an invalid hostname. Indeed, 
foo.troll.no doesn't exist, but foo.europe.nokia.com does]

-- 
  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/277bf336/attachment.sig>