want to prevent people from making mistakes?
linuxguy123 at gmail.com
Sat Dec 6 16:17:27 UTC 2008
On Sat, 2008-12-06 at 08:42 -0800, Fred Silsbee wrote:
> put F10 back in beta
I don't want to knock Fedora, discourage developers or encourage certain
people to rant unconstructively, but I half heartedly agree with this
F10 is a great release. KDE4.1.3 is simply stunning. But its only
*just* ready to be used. Maybe not even so.
In my mind the Fedora releases have been getting less and less suitable
to actually use. Couple that with the fact that the support lifespan is
realistically less than 1 year and its getting hard to justify spending
time with Fedora releases.
I know all about the bleed edge credo. Yeah, whatever. Its a crutch
for those that don't want to focus on the real issues. If the ultimate
goal of Fedora is to release usable software, I don't think we are doing
anyone any favors by releasing things prematurely.
If there was one thing that I could change in the Fedora system, it
would be increase the quality of what gets released and to spend more
time and energy fixing what gets released before the next release goes
I think part of the problem is the way the release goals are set. As
soon as a release is released, developers get into a big race to see how
much stuff they can get ready to be accepted into the next release,
rather than focusing on fixing bugs in the current release. Although
this post gives me cause to think that is going to change going forward:
Another thing that bothers me is that we seem to see the same sort of
bugs in the same areas release after release. Case in point:
networking. Printing. Rendering bugs in Konqueror. There are others.
Are we really making progress when the same areas have the same bugs
release after release ?
The lack of a working ksynaptics application is really bugging me right
now. It worked beautifully in F8, but its been broken in F9 and F10 and
nobody seems to be interested in doing anything about it. Is it going
to work in F11 ? Who knows.
I have a few suggestions to help with the situation:
1) new submissions on a package should not be accepted until the bugs in
bugzilla are taken care of. This would enforce a "fix bugs first"
2) To remove the pressure on the developers to jam their new features
into the next release, there should be a stabilization period after a
release where the developers focus exclusively on issues that arose in
the currently released software before the deadlines for the next
release is set. And the release dates shouldn't be fixed. That system
cannot cope with buggy releases.
So a release would go through the following steps:
- set release goals and date
- prerelease next release
In all cases the next release date would be 6 months from the date that
STABILIZATION is achieved. Rather than 6 months from the date that the
last release occurred. I know that might make the releases slip to less
than 2 per year, but I think the quality would climb significantly.
So a release could have 3 states: prerelease, released and stable. I
know that the repo for releases is called stable, but the released
software is often far from stable.
3) I think that pre release live CD or even DVD ISOs that allow data
retention should be made available earlier and more frequently. This
would encourage more beta and pre release testing.
Unless the prerelease is available in a non destructive manner, on a
Live CD or via a special installation method and I have a way to have my
data retained, I am not going to test it much if at all.
We need to have ways to run pre release software in a way that we can
use it for everyday work and it doesn't ruin our installations. We need
to be able to jump back to a stable release in an instant.
I know that in some cases a bit of data may be lost, but I think I could
live with that.
What I can't live with is installing prerelease software, having it
wreck my "real" installation and then have to reinstall my real
installation. For me the process of reinstalling is several DAYS of
Ubuntu seems to have this down to science. Right now you can test
KDE4.2 on a production installation without wrecking things:
I have very big expectations for KDE4.2, not the least of which is for
it to be available in Fedora near its release date in January and for it
to be stable. The sooner lots and lots of people start using the hell
out of it, the sooner we flesh out the bugs and see how good it actually
Here is one example of something that is being handled really poorly and
seems to have no solution in sight. The developers don't seem to care
at all about the end user.
KDE4.1.3 makes heavy use of graphics acceleration for the folderview
Nothing wrong with that, but a) older video cards don't have graphics
accelerators and b) certain nvidia card drivers don't work with it
My laptop, a brand new HP HDX9494 with an Nvidia GeForce 8800 GTS card
actually stalls when using plasmoids. To the point that they are
unusable. For those that aren't aware, folderviews are (supposedly) the
backbone of the KDE4 desktop paradigm. Folderviews worked fine on my
computer up to and until KDE 4.1.2.
So I entered a bugzilla report on this issue and did a bit of background
research. https://bugzilla.redhat.com/show_bug.cgi?id=473446 The
developer's response ? They tagged the bug as UNFIXABLE.
Do they create a mini application to help the end user tune their video
card to work properly ? Nope.
Do they state that they have contacted NVidia and the issue is being
sorted out ? Nope.
Do they provide tips or a different version of folderview for people who
have video cards that don't support acceleration ? Nope.
The user is left to figure things out for themselves. Go manually play
around with your xorg.conf file. Which has been the norm for nvidia
users since RH8 days, except that livna, now RPMFusion finally came to
the rescue recently.
At this point I have to say that back in KDE 4.0 and KDE4.1 my computer
didn't have a problem with folderview. Meanwhile development continues
on KDE4.2. No matter that folderview doesn't work for 20% of the user
Here is a really radical thought... if we want to get serious about bugs
and code quality, every 2nd or 3rd release should be bug fixes only.
Thanks for listening.
More information about the users