Re: Quo vadis, GNOME? (was: Getting Bugzilla support into Bug-buddy)
- From: Daniel Veillard <Daniel Veillard imag fr>
- To: Alan Cox <alan redhat com>
- Cc: Daniel Veillard imag fr, gnome-hackers gnome org
- Subject: Re: Quo vadis, GNOME? (was: Getting Bugzilla support into Bug-buddy)
- Date: Wed, 7 Feb 2001 13:19:38 +0100
On Wed, Feb 07, 2001 at 05:31:51AM -0500, Alan Cox wrote:
> > What is missing there ? Maybe I'm just too disconnected but my understanding
> > is that the frozen libraries are in a stable state and people are fixing
>
> They arent stable, scan the number of things in the debian-bugs
/me makes some really nasty sounds ...
Well if people don't report bugs to the source of the software, there
is only a small probability that it get addressed in a timely fashion !
For my information I looked at "libxml" => nothing, "gnome-xml" => nothing
and "gnome" led to 1 result "#79113: gnome: gnome is unable to play sounds"
Now, how am I supposed to work out and find where the bug reports are ?
More generally how should we process bug report on a large scale ?
Debian is unlikely to be the only case, I can see Ximian, Sun, Eazel,
Red Hat getting bug reports though their own custommer support. Should we
manage this flow ? How ? We can try to import bugs but that may get
fastidious (think about the 100+ various Linux distro, not all have bugs
reporting mechanism with possible Gnome entries but trying anything
extensive won't work !)
We can certainly discuss with the members of the foundation on importing
their related bugs but clearly the right way to do this is to get the
pointers right (bug-buddy being the systematic approach).
User X using distribution Y hits a bug which may be related to package
Z shipped from Gnome-1.4, how do we get the information ? Who should process
it ? A dormant bug in debian database is not useful if there isn't
someone looking at it and possibly forwarding it to the main Gnome bug DB.
> > policy to find the resources in the corporate world to assign bug fixing
> > to a given person. It would be a shame if we had to do this, but that's
> > one of the opportunity of getting large and funded and we should have
> > no hesitation to make use of this lever if this is needed.
>
> It's worth noting that what has slowly been happening to gnome happened to
> the kernel for a while too. Vendors sucked a lot of maintainers out of the
> main pool of developers hacking the kernel. Many of them got tangled up in
> Linux project management, others disappeared into achieving great and clearly
> important and critical things (in their eyes) and the core code - especially
> drivers really started to go to pieces. Nowdays we have vendors and hackers
> aware of that and there are people (Jeff Garzik is a great example) who is
> funded by Mandrake primarily to clean up other peoples crap driver code.
Okay we need people paid for doing the dirty job. Ximian did the packaging
(getting some undeserved IMHO flames in the process). Problem too is that
it's always problematic, because some people will have the feeling that one
tries to step on their toes, and getting good bug fixes is *hard* as you
know. Just look how we reacted (me included :-\) when Sun's engineer stated
he would look at 64bits cleanness of the code. We collectively need to
accept the fact that at some point one need to pass the baton for some tasks
like bug fixes in stable release (as an example I did change the HACKING
in libxml1 frozen branch to state, "If you find a bug, fix it first, commit
then send me a note").
> One mistake we made in the kernel was also a lack of willingness to simply
> clean out unmaintained code and stop shipping it. For 2.4 we marked some
> drivers as obsolete and left them not compiling to see if anyone cares
> but we've yet to get that right to the degree folks sensibly didnt ship
> half of gnome-utils last time.
I must admit I use only a very limited subset of Gnome apps, but except
some annoyances with gnome-terminal I didn't get a crash of any core gnome
tool in the last 6 months (but I keep my desktop more or less up-to-date
using Helix packages).
Now is it better to not ship an app which may crash in some circumstances
or to leave a hole in functionalities for everybody ? I don't know, maybe
as Gnome matures we should switch progressively from No to Yes ...
> And no I see nothing different now between the debian 'if its got critical
> bugs we wont ship it' event, the kernel mess mid 2.1.x and gnome. Im not
> trying to be downhearted about it either. In fact its worth noting both
> other victims of this disease recovered 8)
What amount of diet/drugs were needed ?
Daniel
--
Daniel Veillard | Red Hat Network http://redhat.com/products/network/
veillard redhat com | libxml Gnome XML toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]