[Development] Removal of xlib plugin - a possible disaster.

Robin Burchell robin+qt at viroteck.net
Sun Mar 18 11:23:51 CET 2012


On Sun, Mar 18, 2012 at 7:59 AM, Rick Stockton
<rickstockton at reno-computerhelp.com> wrote:
> (3) Wondering if my Distro was "too old", (and most of it's RPMs were
> built in April of 2011), I just upgraded to Mageia-2 "beta-2". I no
> longer get SIGSEGV, but I get a problem which _could_ be closely
> related: referencing an Undefined Symbol related to WM hints.
> https://bugreports.qt-project.org/browse/QTBUG-24835

Thanks, that's useful. I can't say I've run into it personally (I'm
running Fedora 16), but hopefully can try help take a look at that
specific example.

> I can't think of a WORSE spectacle, for the reputation of Qt-Project,
> than the Release of an Alpha Build in which large numbers of exerpienced
> Qt users on Linux Linux _might_ be unable to use the XCB plugin and show
> a main Window, before getting some kind of 'ABEND', with _any_ of our
> own provided examples.

I agree: If we are shipping an alpha in which the xcb plugin is
unusable for large numbers of people (though this needs to be
quantified - how many people are hitting these problems?), then we're
doing it wrong. We shouldn't ship something that doesn't work.

> With these two bugs present (i.e. SIGSEGV happening on some "older"
> Distros, and "Undefined Symbol" happening on RPMs built just 6 days
> ago), you NEED to have an alternative, EASY plugin for these people to
> use. Even at alpha.

No. As I said, the problems need to be *fixed*. Providing workarounds
just means that people that can _find_ the workarounds keep using
those workarounds, those that _can't_ find them think "Qt 5 is crap,
it doesn't work", and when that workaround is under/unmaintained code,
that won't leave a good impression anyway.

> (B) stop ignoring the IRC "I'm getting
> 'segment fault' with an example program" postings

IRC is *not* a bugtracker. It's transient. You're shouting into a
void, and if someone who happens to be able to help you reads what
you're saying, and has some time to help you - great. That doesn't
mean you should treat it as the one place to report issues. Writing to
the mailing list is a more sensible idea, as it has a much more
permanent record. Filing bugs (or even better: patches), and bringing
them to the attention of the people who work on that code (through
mailing lists, or if you _know_ who to speak to, IRC) is even better.

Relatedly, quoting you from Gerrit:

> I have been present when OTHERS have brought up the same problem (crash with
> SIGSEGV, before bringing up the main window) on OTHER Distros, starting sometime in mid (or late?) February.
>
> No one addressed it, and I've got no experience in this area. [w00t has been logged
> in at the time of least 2-3 of those queries... but possibly in unannounced "back later"
> mode at those times.]

Unless something goes wrong with my server, I'm always "connected",
but not necessarily reading, or even in front of the computer. I
connect to IRC through a server, and then connect to _it_ when I'm
around. Sometimes, I might read things that happened while I was away,
but not often: I have two seperate such connections (one for work, one
for "personal" stuff), and between them, I'm on around 70-80 different
channels. If I tried to keep track of everything that happened in
those channels all of the time, I'd never get anything else done. So I
don't. I know that many other people use IRC in similar ways, for
instance, read up on "Quassel", which is a Qt-based tool for
permanently-connected IRC, which I know many of the #qt-labs folks
use. This is part of what I mean when I say you're shouting into a
void on IRC: there may be 283 people in a channel (#qt-labs as of
now), but a large proportion of them may be asleep, off making a
coffee, working on something else, or just not have anything relevant
to say.

>, and POSTPONE ALPHA until we've got them fixed.

I think we'd need to really have an idea of what the problem is, how
many people it affects, and the effort to fix it, before we can make
that call. But yes, as I've said: I don't think that shipping broken
code is a good idea.



More information about the Development mailing list