Now Alan Cox has left the Linux developer community:
See what you did Fedora? You drove him to Ubuntu, and he couldn't take it for very long! Now he's gone.
Source: https://wiki.archlinux.org/index.php/SystemdAdding your user to groups (sys, disk, lp, network, video, audio, optical, storage, scanner, power, etc.) is not necessary for most use cases with systemd. The groups can even cause some functionality to break. For example, the audio group will break fast user switching and allows applications to block software mixing. Every PAM login provides a logind session, which for a local session will give you permissions via POSIX ACLs on audio/video devices, and allow certain operations like mounting removable storage via udisks.
this is coming from someone that used and liked fedora 17:
fedora 18 is not only the worse fedora release to date, it's also a broken distro that should have never been released.
The writing was on the wall and when, month after month after month, they noticed how broke everything was THEY SHOULD HAVE SIMPLY DELAYED OR CANCELLED fedora 18
jump straight to 19 or release 18 in 19's date....
Alan Cox wasn't the only one jumping to ubuntu
hell even the alpha right now is 238912833 times more stable than fedora 18
We have a defined set of release criteria for Fedora and a process that ensures it reaches those criteria. The F18 release was delayed because we were going through that process: once we hit the criteria, it got released. The criteria do not say 'it must be perfect', and it's entirely the case that some releases exceed the criteria while some may only hit them. This is a thing that happens in software development. Given the nature of Fedora and the development cycle we're working on, we are never going to hit a perfect release every time, especially when that release involves rewriting the entire installer.
"Fedora 17 had an installer that worked just fine. So you could have continued to use that, and optionally provide your new installer to those who want to test it."
That's not how things work in practice at all. You are by all means free to confirm this for yourself: take the Fedora 17 installer, plop it down in the Fedora 18 package set, and try to build an installer image. Ten to one it won't even compose, but on the offchance that it does, the composed image will _certainly_ be entirely busted. It won't work at all and will probably eat babies.
This is actually one of the major reasons we're doing newUI in the first place: a significant part of the work involved in maintaining any OS installer is simply in keeping it up to date with the rest of the system. You can't just take the installer from one release, shove it in the next, and call it good. It has to be maintained to account for changes in the rest of the system. oldUI in particular was getting to the point where maintaining it from release to release just so that it worked _the same_ - not noticeably better - was taking up a significant proportion of all the resources we had for installer development. That meant we couldn't really do a lot of work on making the installer better.
One of the major advantages of newUI is that it should require rather less running-to-stay-in-place maintenance work than oldUI did. However, as long as we do something like your plan - variations on which were suggested umpteen times by people who are not aware of the details - we were making the resource problem worse, not better: because we have to _both_ maintain oldUI _and_ work on newUI. newUI work did not start in the F18 cycle, it started back around the F15 cycle; so for three releases the anaconda team has been trying to work on newUI while simultaneously maintaining oldUI. This causes significant stress on them, slows the pace of newUI development, and probably means oldUI wasn't getting quite all the love it needed.
So any scenario in which we're continuing to work on both installers - let alone one where we actually offer and to some extent support both installers, which is pretty much the nightmare scenario - is a vary bad and unsustainable one.
This whole setup gives us a very strong reason to get newUI in as default as early as practical: now we have hit the point where newUI is in as default, we're in a much better place. We can kick oldUI to the curb, no-one has to work on it any more. Everyone is dedicated to making newUI better, and now we have a release out where newUI is the only option, we are getting lots of feedback on what bits of newUI need improving. The pace of newUI development will be far more rapid than it would have been had we tried some kind of do-both-at-once approach.
"You could have recommended users to ditch the installer altogether and link to a document instead which describes manual partitioning + febootstrap as the preferred install method (Gentoo does it like this, and Arch has recently adopted this way too)"
That's...interesting, but really not in line with how Fedora rolls, I don't think. It would have been just too drastic for a single release. newUI really isn't that terrible, you know; quite a few people have been saying 'it worked fine for me, I don't get the fuss'. It's at its most awkward when you're using custom partitioning with existing complex layouts, and I think that describes quite a few Phoronix users as this is one of the places for distro tweakers, but it doesn't describe everyone. If you're just doing a fresh install to a VM, for instance, it rolls fine. Even custom install to an empty disk works pretty nicely.
"You could have labeled Fedora 18 as "Forever Beta" and not make it an official release, just something for the interested."
That again would have been a valid approach, but I'm not sure it buys us a lot. At this point we have the same product and it's just about massaging the messaging. That's something we already tried to do with the release announcement and other release documentation, and see how much slack that's bought us.
With hindsight there's a reasonable case to be made that it might have been better to wait for F19, but that's a very difficult call to make six months ahead of time. The practicalities described in the previous post mean it's not really viable to jump then jump back two months later, because then you have to retool and try to fix up oldUI for the new release, which is just as bad as trying to hack newUI into usable shape. It's pretty much a one-time call.