Not too impressed with the quality of F14 at this time

Adam Williamson awilliam at redhat.com
Mon Sep 13 18:25:11 UTC 2010


On Mon, 2010-09-13 at 14:06 -0400, Jonathan Kamens wrote:
> On 9/12/2010 3:27 PM, Adam Williamson wrote:
> > Sorry to hear you're having trouble. Let's take a look through the bugs.
> > I can't reply in line as Evo is being too 'clever' about your table,
> Hmm. Maybe you should file a bug about that. ;-)

It's not really a bug, just Evo treats formatting in emails as
formatting in replies and doesn't let you split up the table and put
lines in the middle of it. It's intended to behave that way.

> > 632939 - as Lennart says, seems a bit confused; if you could follow up
> > with more information it'd help.
> Done.
> > 632934 - are you sure this is new?
> Not certain. Would have expected to have found another bug about it when
> I searched if it wasn't new, but didn't find anything. But you may be
> right that it's not new.

Searches don't return closed bugs by default. If someone filed a bug and
the maintainer decided it wasn't actually a problem, the bug would be
closed and a search wouldn't return it.

> > I vaguely recall seeing this message
> > all the time. atk is accessibility stuff, so you don't need it if you
> > don't need accessibility assistance. I'm not sure if we intend it to be
> > installed by default or not. This kind of message isn't *always* a bug
> > to be fixed; sometimes apps are set up to just always call something and
> > then use it if it turns out to be there but not use it if it isn't, and
> > in that case it's not always a problem that there's an error like this.
> > Matthias is the right assignee, he should know if this is a problem or
> > not.
> I don't think GUI apps should be logging seemingly alarming messages
> like this to stdout if they aren't actually a problem. If the
> possibility that the referenced shared library isn't there is expected
> and normal, then attempts to load it should fail silently.

Well, that's arguable. Many developers prefer apps to be 'chatty' and
report things like this for informational purposes. It's a design
choice, really.

> > 632932 - no points for h264 format video ;)
> Why? Is there a patent issue? It's the default codec VLC uses when doing
> screen captures, and it's also by far the best codec I've found for
> capturing this sort of thing. Is there a free alternative with
> comparable performance?

h264 is patented up the wazoo, we can't ship encoders or decoders for it
by default. webm is the current flavour of the month for a free
alternative.

> > It seems like only a few of the bugs are really significant - the
> > network and gnome-keyring issues - and the devs are working on those.
> > The rest read as pretty minor to me; do let us know if any of them are
> > more significant than they immediately appear.

> You're right that a number of the issues I encountered are seemingly
> minor. However, when it comes to software quality, "where there's smoke
> there's fire" has rarely gone wrong for me... Lots of seemingly minor
> issues with a software system are a pretty good indication of lower
> overall quality and therefore a hint that there may be larger, lurking
> issues that have not yet been uncovered.

I don't really subscribe to that point of view. Maybe it works for small
applications which are written by a single author or a small group, but
Fedora is nothing like that; it's a collection of thousands of bits of
software from disparate sources. Most of the actual *coding* in Fedora
isn't under our control. So small issues are always going to show up,
there's nothing we can do about that besides stop taking new code from
upstream, and that's never going to happen (or somehow gain
exponentially more QA resources to identify all the minor issues, and
development resources to fix them all). Given the resources available to
any given Linux distribution, it's usually sensible to assign minor
issues a low priority and concentrate on identifying and fixing major
ones.

> > Even if this isn't new you should file a bug as it's the best way to
> > make the developers aware of the issue. If you've already filed a bug
> > before, update it to say it still exists in F14.
> I will try to do that, but it is somewhat disheartening, because
> feedback I've seen here and in bugzilla in the past suggests that the
> nouveau driver is not particularly well-maintained and isn't likely to
> be any time soon. When it comes to taking the time to file good bugs,
> nobody likes to feel like they're wasting time on bugs that aren't ever
> going to be addressed.

I don't know where you heard this, but it's not true at all. nouveau is
one of the most intensively developed components in Fedora, in fact, and
Red Hat pays Ben Skeggs to work on nouveau full time (he's one of the
main upstream developers of the driver). He spends a lot of time working
on Fedora bug reports for nouveau.

> Thanks very much for the detailed response, Adam.

No problem at all.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



More information about the test mailing list