On Sat, 2012-11-03 at 00:44 +0100, drago01 wrote: > > The number of variables involved in one is astronomical. Note > > that neither Red Hat nor Microsoft actually support major version > > upgrades for their operating systems, > > Microsoft does. They do even sell upgrade boxes ... Well, it's a bit complicated. They didn't support 'true' upgrades from XP to Win 7, for instance - the 'upgrade' process just did a fresh install and then tried to copy back 'important' stuff like your desktop layout. And if it goes wrong...well you can call tech support and they'll do their best, but you're not getting a refund. And Windows upgrades *do* go wrong. Corporate deployments of Windows, to my knowledge, virtually never rely on the upgrade functionality. > > much lower levels of churn, > > No they actually have way higher levels of churn ... just think about > it ... in fedora we are talking about 6 months worth of chrun not 5+ > years. Can't speak for Red Hat but maybe this is one of the reasons > why they don't support upgrades. True, that was a bad point; the average rate of churn is lower but the churn between any two releases is big. > > (Also note how much trouble phone companies have > > updating Android.) > > That has more to do with how bad forking is for maintenance ... we > don't really have this problem in fedora (ubuntu is driving themselves > into this corner but that's OT). > > > I also know what we do to test upgrades before we sign off on a release, > > which is 'do a clean install of F-N in a VM and check it can be upgraded > > to F-N+1'. If that passes, we ship. That is not a level of testing which > > allows me to declare with confidence that our upgrade process is solid > > and reliable ;) > > Well it means that the process works. Everything else are bugs in the > packages itself which you would have hit during a normal yum update > otherwise. That's an oversimplification. A stock install only has a small part of our *official* package set installed. Any given user's system might have any of the others installed, or any third party repo (including a graphics driver from a third party repo). On some upgrades we reinstall the bootloader or do other disruptive things. And again, I'm not saying we could do upgrades better; the fact that 'it'd be just as bad with yum' is besides the point. My point is that major version upgrades are such an intrinsically unreliable operation that any workflow which requires people to do one once a year has problems. They're not something you can realistically expect people to rely on. Microsoft don't really expect you to upgrade Windows. They expect you to buy a computer with Windows X on it, use it for three years, then throw it away and buy a new computer with Windows Y on it. Red Hat expects something similar for RHEL - they don't expect people to upgrade systems from RHEL 5 to RHEL 6 on the fly. Corporations spend *years* planning OS migrations, which usually involve buying new hardware, not upgrading existing systems. This is an implicit acknowledgment that upgrades are just not a great way to do things. I don't think we can realistically expect Fedora to do it massively better. If you're going to do stable releases of your operating system, it just doesn't make a lot of sense to make people upgrade every twelve months. If you're going to have stable releases, you should maintain them long enough that people don't really rely on the upgrade function. That seems to be how the big boys do it. If we can't do that, are the stable releases really achieving much? > > In a rolling release model, everyone deals with foo-1.0 to foo-2.0, then > > a week later they deal with bar-1.0 to bar-2.0, then a week later they > > deal with monkeys-1.0 to monkeys-2.0...in a 'stable' release model, > > everyone gets to deal with foo, bar, monkeys and five hundred other > > changes all at once. Which is chaos on a stick. > > But then you have to deal with this kind of stuff every time you > update something. That's not really usable if you want to get work > done. > While the bigger upgrade leaves only hits you once or twice a year. My position is that the people who use Fedora and the kind of people we really _want_ to use Fedora can cope with it. Remember, I'm not proposing it be as bad as Rawhide; we have the whole Bodhi karma process to work with. I think it's plausible to design a process where people only rarely have trouble with updates, even ones that are theoretically pretty messy; about the same frequency they'd have had trouble with upgrading our stable releases. Remember, I mentioned the kernel team as a model; despite my sound gripe, they seem to be managing pretty well in bumping older releases to newer kernels without causing massive breakage. They do cause some problems...but we get 'some problems' anyway. -- 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
