On Sat, Dec 6, 2008 at 10:17 AM, Linuxguy123 <linuxguy123@xxxxxxxxx> wrote: > 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 > sentiment. And here we go .... > F10 is a great release. KDE4.1.3 is simply stunning. But its only > *just* ready to be used. Maybe not even so. Well Fedora didn't develop KDE 4.1.3, they just package it, and help with testing. > In my mind the Fedora releases have been getting less and less suitable > to actually use. Entirely a matter of opinion. I have a machine which boots with full wifi on F10 where as in F10 it took me weeks to get some basic wifi going. > 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. Well really, I don't think people use Fedora for support. > 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. here in lies the problem. The real issue for a lot of the devs is getting work done, fixing bugs, writing new features. You want their focus to be polishing it all up for you to enjoy. > 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. The ultimate goal of Fedora is promote use and development of free software. I'd argue it is the best Linux distro in this regard > 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 > out. Well, you've found the issue. You're not doing it, and it doesn't magically get done. I know this sounds like the typical "do it yourself", but you have to be realistic, someone has to do it. > 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. Fedora is a distribution, not a single app. They collect, package and help test software. Only a few software projects fall directly under Fedora. > Although > this post gives me cause to think that is going to change going forward: > > http://lwn.net/Articles/309678/ > > 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. Yes, and Fedora is to blame for all those things? Seriously? > There are others. > Are we really making progress when the same areas have the same bugs > release after release ? Well, unless they are in bugzilla you cant' say they are the same bugs. > The lack of a working ksynaptics application is really bugging me right > now. Seriouslly? Fedora is a distribution. They are not the developers of ksynaptics. They package wgat the devs release. > 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. Well one would think you know since you have expressed an interest in know. If the people who suffer the bugs don't care to know, what hope is there for busy packagers? > 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" > mentality. Packages don't get accepted if there are blocker bugs against it > 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. Which developers would this be? > So a release would go through the following steps: > > - prerelease > - release > - stabilization > - 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. So you're asking for more commitment in terms of time, and bandwidth, these are not infinite supply. > 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. Run rawhide on one of the many freely available virtual machines, or commit some hardware to testing. > 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 > work. > > Ubuntu seems to have this down to science. Right now you can test > KDE4.2 on a production installation without wrecking things: > > http://hehe2.net/linux-general/try-kde-42-now-in-ubuntu/ > > 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 > is. > > Example > > 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 > plasmoid. > > 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 > either. > > 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. What part of this problem suggested that it wouldn't be a better idea to use bug at KDE and just reference the bug in bugzilla.redhat? > 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. Well, they did say that they have been working with Nividia to fix the problem with Nvidiias cards > 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 > community. > > 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. > > > > -- > fedora-list mailing list > fedora-list@xxxxxxxxxx > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list > Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines > -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
