On Fri, 2012-11-02 at 16:31 -0600, Kevin Fenzi wrote: > On Fri, 02 Nov 2012 15:17:02 -0700 > Adam Williamson <awilliam@xxxxxxxxxx> wrote: > > ..snip... > > > If you're using a Fedora release today you're _already_ fighting OS > > bugs more often than most people do, I'd say. I disagree with drago's > > assertion that my description was of people who use Rawhide. It was > > not intended to be, and it was drawn from the experience of me and > > other people who do not run Rawhide. I almost never run Rawhide, only > > Branched. > > Perhaps you have your head too much in the Branched world right now? Not really. I think I have my head more in the 'real' world than some Fedora folks do though ;) I usually run Branched on my desktop and current stable (F-N) on my laptop. How stable is that? Well, the sound on my laptop broke with F17. For several months. It only got fixed because I took the bug upstream and then ensured the fix got ported down into Fedora...that's the experience that *someone who knows how to get people to fix his bugs* has with our product. Imagine the experience a normal person has. > In my experience, in the last few years, Fedora stable releases have > become much more stable. My "stable" boxes here at home I have not > really had to poke at since I upgraded them to Fedora 17. I apply > updates every few days and things keep working along fine. > > In previous cycles there were some real nasty brown paper bag type > blowups that required me to do things to downgrade or tweak to keep my > stable version working, that (knock on wood) hasn't happened in f16/f17 > in my experence. > > I realize there are bugs and problems that hit, but I think the stable > updates policy has helped keep those down. (Cue KevinK to come in and > shout and tell me how wrong I am, etc etc) Sure, like I said in another mail, we've got better at that than before. But as I also said in the same mail, you still have to do a version upgrade every twelve months. That alone is ridiculous for a 'stable' operating system. I don't think we destabilize things - in the sense of 'you update and your machine stops working' very often within a single one of our stable releases. That isn't my point, really. My points are more: * Upgrading every year, with an unreliable upgrade process, is not something you have to do with a proper stable OS * We do not insist on a level of polish or lack of functional regression in our stable releases which is any way consistent with a true productized general purpose OS I'm as well placed as anyone to know _exactly_ what we as a project are happy with signing off on as a final release, and based on my experience working on, using, and doing user support for various distributions and operating systems, I'm happy to maintain that that level is nowhere near a level suitable for a general-purpose stable OS. Our standard for a final release is, broadly, that the installer works pretty well, there are no giant booboos on the desktop, and you can run the updater. We don't care if a feature that was introduced in the previous release is completely broken, unless it affects the critical path, we just say 'fix it with an update'. We don't hold releases for cosmetic bugs, even really obvious ones. We don't hold releases for usability issues. These are all things that serious grown-up operating systems do. That's fine. My posts have a general negative tone just based on the way I'm constructing my argument, but it's important to realize I don't think this is a _problem_. I think what we achieve is roughly what many people who run Fedora want. But we _only_ achieve that level, and we really don't need this unwieldy system of maintaining four releases at a time to achieve it. My fundamental argument is there's a bit of a disconnect between our release process - which is sort of aping the way a stable general-purpose OS would be released, but on fast-forward and with far fewer resources - and our actual goals for the project and the standards we really enforce. We don't _need_ the heavy, constant release cycle we currently employ in order to deliver the good things we already currently deliver. Anyway, I think the point is mashed into the ground by now, so I'll stop. My proposal is more about trying to get people thinking at a fundamental level than it is necessarily something I actually expect the project to adopt wholesale - I just want to make the point that, in designing whatever changes we may make to our processes, we should keep a realistic view of what Fedora is actually _for_, and not over-engineer things. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
