[PATCH] Get rid of QPainter warnings

[Robert Knight]

Hi,

> So you see how changing it would meet some resistance.

It doesn't need to be replaced, just expose more information to users.
The task tracker entries currently consist of a terse description of the issue,
Qt versions affected and a status.

I am correct in understanding that commercial customers have other facilities as well? 
The TaskTracker FAQ mentions 'TaskTracker accounts' but I couldn't find any information on 
how to sign up for one.  Buried in the support pages is a brief mention that users with a paid
support contract get 'personalised access' to the Task Tracker so I presume this is what the FAQ
is referring to.

I understand why Trolltech needs to give priority to bug fixes and features requested by its paying
customers (via. votes or some other mechanism) but not being able to at least comment on or view other
users comments for a report is quite frustrating.  

Regards,
Robert.


On Mon, 2008-04-07 at 11:37 +0200, Thiago Macieira wrote:
> On Monday 07 April 2008 08:48:23 Aaron J. Seigo wrote:
> > > * point again out the flaws the TT-bugtracker has and that this may
> > > (well, at least for me) part of the reason why no feedback is provided.
> > > That's a pure technical critic and married with a suggestion like to jump
> > > to something like bugzilla or another ticket-system that allows to be
> > > more transparent and to easy follow the process of a bug+fix would be
> > > even constructive.
> >
> > please not bugzilla (i hate that thing), but i have to +1 that the TT
> > bugtracker is just horrible to use from the outside =/
> 
> But when used from the inside, it's very nice, with a Qt-based rich client. It 
> also contains 200,000 tasks with 6 years' worth of history. Not only that, 
> the same database is used to track tasks unrelated to development (to-dos for 
> sales and marketing, for instance).
> 
> So you see how changing it would meet some resistance.
> 
> However, if we decide to go ahead and switch to a decentralised VCS for our 
> internal development, we may have to revisit the issue.
>