Qtopia-interest Archive, February 2008
What is your approach to handle Qt bugs?
Message 1 in thread
Hey,
I'm still browsing the core/server directory and I have stumbled across
comments like:
phone/ui/griditem.cpp:206: // TODO !!!!!!!!!!!! THIS HAS GOT TO GO.
Waiting for Oslo...
phone/ui/selecteditem.cpp:801: // TODO: This is because Qt's QTimeLine
has a bug which doesn't reset the frames
phone/ui/selecteditem.cpp:956: // TODO: This is because Qt's QTimeLine
has a bug which doesn't reset the frames
Let me explain my point of view:
- These areas are marked with "TODO" - Good!
- They do not list a bug number - Bad!
- They might go unfixed in future versions of Qtopia - Bad!
So did you file bug reports? Is 'Oslo' informed at all? You might want to add
a #warning or #error and guard this with QT_VERSION so these issues don't get
lost. For people outside of Trolltech the following would be really
appreciated:
- File a bug when you find it
- Make sure it is public
- Write the bug number into the code so people can search for it
in the public task tracker!
z.
--
[ signature omitted ]
Message 2 in thread
Hi Holger,
We don't apply bug numbers in the code, as overtime, this would make
things really messy.
Holger Freyther wrote:
> Hey,
>
> I'm still browsing the core/server directory and I have stumbled across
> comments like:
>
> phone/ui/griditem.cpp:206: // TODO !!!!!!!!!!!! THIS HAS GOT TO GO.
> Waiting for Oslo...
> phone/ui/selecteditem.cpp:801: // TODO: This is because Qt's QTimeLine
> has a bug which doesn't reset the frames
> phone/ui/selecteditem.cpp:956: // TODO: This is because Qt's QTimeLine
> has a bug which doesn't reset the frames
>
>
> Let me explain my point of view:
> - These areas are marked with "TODO" - Good!
> - They do not list a bug number - Bad!
> - They might go unfixed in future versions of Qtopia - Bad!
We have to prioritize. We have a limited amount of resources available.
>
> So did you file bug reports? Is 'Oslo' informed at all?
It depends on the developer involved. Mostly, yes, Qt developers are
informed about the bugs we find in Qt. But as Qtopia development is
behind what Oslo is developing, we sometimes are forced to keep our own
set of patches for the specific version of Qt that our releases come with.
> You might want to add
> a #warning or #error and guard this with QT_VERSION so these issues don't get
> lost. For people outside of Trolltech the following would be really
> appreciated:
These would generate a warning or error message from the compiler, and
is against our policy.
Some compilers fail on warnings, and we try to keep these to a minimum.
>
> - File a bug when you find it
We generally do. Although most likely will just go and fix it.
> - Make sure it is public
individual developers cannot make a bug public, nor can we see if it is
public. In fact, I am not sure who can make it that way. Mainly only
bugs generated from the bug report form are public, I believe.
> - Write the bug number into the code so people can search for it
> in the public task tracker!
This would make the code really especially messy over time, not to
mention most likely divulge customer information. A bug number for code
that is years old is irrelevant.
>
--
[ signature omitted ]
