Forgot your password?
typodupeerror
Operating Systems Linux Business Red Hat Software Software Linux

Fedora 18 Release Slips Another Week 68

Posted by Soulskill
from the stay-tuned-for-the-thrilling-conclusion dept.
An anonymous reader writes "The next major release of the Fedora Project's GNU/Linux distribution (named Spherical Cow) was originally scheduled for November 16th. However, an ambitious set of new features has resulted in the project slipping way past its scheduled release. It had fallen three weeks behind before even producing an alpha release and nine weeks behind by the time the beta release was produced. A major redesign in the distribution installer seems to have resulted in the largest percentage of bugs blocking its release. The set-back marks the first time since 2005 in which there was only one major Fedora release during a calendar year instead of two. Currently, the distribution is scheduled for release on January 15th."
This discussion has been archived. No new comments can be posted.

Fedora 18 Release Slips Another Week

Comments Filter:
  • by Anonymous Coward

    I got tired a long time ago with the fast update cycle that Fedora uses. I've moved on the CentOS because of it. I need a stable workstation. Fedora is all well and good if you want to play with the bleeding edge, but I can't afford that on my systems anymore. I'll probably play with it in a VM to see what's up (or live CD it) but that's about it.

    • by Ignacio (1465) on Friday January 04, 2013 @12:18PM (#42476077)

      And no one (sane) hates you for that. Fedora isn't a one-size-fits-all distro, nor do they ever want to be one.

    • If only there was a distro that separated stuff into stable, testing and unstable taxonomies. You could even have a cutting edge experimental branch that could possibly break everything.

    • Fedora is all well and good if you want to play with the bleeding edge

      Well, yes, that's what it's for, isn't it?

      • by donaldm (919619)

        Fedora is all well and good if you want to play with the bleeding edge

        Well, yes, that's what it's for, isn't it?

        If you get the Release Candidates yes, however the final release normally is quite stable and IMHO every bit as good and reliable as the other distros. In fact I actually use Fedora as my primary OS (all others are virtualized) professionally.

        I normally don't recommend an upgrade when going from one major release to another (ie, 16 to 17 to 18) but a fresh install which actually is quicker to do if you separate your personal data from the operating system and note down any necessary configurations that w

    • by pscottdv (676889)

      Have you taken a look at scientific linux?

        https://www.scientificlinux.org/ [scientificlinux.org]

      It's like CentOS, but is supported with a budget by big-name laboratories.

    • by swalve (1980968)
      Nobody is forcing you to upgrade from a working version.
    • I run CentOS as my desktop and it's great. That's what happens when Red Hat takes a good Fedora release and debugs and polishes it for several years.

      However, there's no doubt that, at its core, CentOS is aging. At some point, I fully expect to move elsewhere because I will want be able to run what I want to run.

      On Fedora 18: I've installed and played with several of the alpha, beta and test candidates. Other than the new Anaconda, this looks like a very nice release. The new Anaconda design, at present,

  • by TheCarp (96830) <sjc&carpanet,net> on Friday January 04, 2013 @12:18PM (#42476071) Homepage

    There is some really delicious irony to a project released named "Spherical Cow" finding that assumptions made in planning were not correct :)

  • rngd? (Score:2, Interesting)

    It's odd that rngd is an 'ambitious new feature. It's been around for years and has never been deployed right.

    Three things are wrong
    1 - It's not on by default
    2 - When you turn it on, the command line options are wrong, so it silently fails.
    3 - When you fix the command line options, it barely feeds in entropy during boot time because the wakeup threshold in the kernel is set too low, so you get the boot time entropy starvation problem, even though you have an entropy source and rngd running.

    Also, if they don

    • I just took a look at Jeff Garzik's notes and it says it has the RdRand extensions, so my expectations are raised a little. Yay.
      Here's what I do on FC17..
      1) Install the RdRand enabled rngd
      2) At the command line, type systemctl enable rngd.service
      3) In /usr/lib/system/system/rngd.service, change

    • by Shimbo (100005)

      It's odd that rngd is an 'ambitious new feature.

      You need to fix your English parser. An ambitious set of new features != a set of ambitious new features.

      • This is true, I hang my head in shame and fully expect to be cast into grammar purgatory on my death. It's still broken in FC17 though.

  • Personally, I think 6 months is way too short of a time to iron out bugs plus insert new features (and then fix those bugs). As we've seen with Ubuntu, the bugs don't get fixed until at least 1-3 months after release. Slackware, for instance, does yearly releases and that seems to work well for them. The openSuSE guys are also considering (although not officially) yearly releases after the QA problems they had with getting 12.2 ready.
    • 6 months is way too short of a time to iron out bugs plus insert new features

      Fedora has become an experimental technology preview platform. It exists for end users to iron out the bugs.

  • systemd (Score:2, Interesting)

    by ak3ldama (554026)

    Porting from sysVinit init scripts to systemd unit files.

    It is not just the new installer, the conversion to systemd is also only at 70% complete. From their Release 18 Feature List. [fedoraproject.org] I am still using Fedora 16 at home as I had no real reason to move to 17 yet and will probably skip it. I am not entirely sure I want systemd instead of sys v init though and might do a review of the choices out there such as arch. I have used Fedora exclusively on the machine since early 2010 ever since the open source ATI drivers came along. Over all it has been a nice eco system.

    • by geek (5680)

      Arch defaults to systemd now also. So if you don't like systems Arch is out.

    • by Errtu76 (776778)

      This is an interesting, albeit long read. I must say, it does wonders for those with an SSD.

      http://0pointer.de/blog/projects/systemd.html [0pointer.de]

    • by AdamWill (604569)

      Fedora has been using systemd for several releases now. You're using it, if you're using F16. The feature is for the conversion of service configuration scripts shipped with Fedora from SysV format to systemd-native format, not for actually changing the daemon.

  • by Lawrence_Bird (67278) on Friday January 04, 2013 @12:46PM (#42476433) Homepage
    I'll grant that my glance was cursory but much of that list just appears to be "making other shit thats been around for a while work on Fedora.XX" Which are unique to Fedora that would compel one to chose it over one of the other distributions (and I hope we are past the point of talking about installers)? This is not a troll, the same question could probably be asked of most Linux distros but as a front page /. post makes Fedora 18 delay seem important I ask about it.
    • by hey (83763)

      Yes that's what distros do. They incorporate other stuff. Fedora is very cutting edge - its the place for new stuff.

    • by AdamWill (604569)

      "Which are unique to Fedora that would compel one to chose it over one of the other distributions"

      That's not really the point of Fedora features. Almost nothing is 'unique to Fedora' because that's not what we want with Fedora. We _want_ other distros to adopt the stuff that originates in Fedora and at RH.

      "and I hope we are past the point of talking about installers"

      Why would you hope that? The capabilities and interface of the installer are one of the major differentiators between distributions.

      The major f

  • The new blackberry 10 integration.
  • by nimbius (983462) on Friday January 04, 2013 @12:52PM (#42476525) Homepage
    The installer UI, and sysv to systemd are things that need to get completed. As of about a week ago i posted a systemd service for slim that hopefully with this deadline extension will get included in the image as opposed to zero-day updates.
  • They should never have merged in the new Anaconda in the state its in. It is not production ready. It is basically impossible to create a new LV or btrfs subvolume and install into it. So you are left with installing into a real partition. And on most of my computers I'm using btrfs or LVM and I've given them the whole HD, so that's not really an option.

    Additionally, the UI for selecting where to install into is so confusing that I cannot say with confidence that the install isn't going to wipe out any existing partitions.

    The old UI was kind of fiddly, and perhaps it was a bit opaque to newer users since it required some detailed knowledge of what a partition was and how it relates to a physical hard-drive, and LVM volume group or a btrfs volume. But at least it worked and you could make it do what you wanted.

    Perhaps this new UI will be a lot better in the end. All I know is that merging the work into mainline Anaconda at this stage of its development was a huge mistake. It means that it will be much harder to go back to the old one should the new UI not be ready in time, or prove to be not-constructible.

    I consider it basic software engineer to never count on a given feature that isn't done (to the point of having had at least some testing) to be available on release. You don't let your salespeople sell it. And you don't announce it. This is something I've always had a lot of respect for Google for. They rarely announce things until they're actually done. Software engineering is too unpredictable to do it any other way.

    • by gtirloni (1531285)
      I tried F18 Beta and the installation was awful. Not very intuitive.

      It felt like they are chasing Ubuntu's installation experience but failing.

      -- Fedora user since Red Hat 4
    • by Anonymous Coward

      Production ready? Who in their right mind uses Fedora in a enterprise environment? Fedora is, and always will be, a test platform for tech that will later go into RHEL and eventually the so-called Gnome OS. I'd never use it for a production system if my job depended on it (which it does).

      • I have a very different standard for 'production ready' for Fedora and RHEL because you're correct. But 'production ready' for Fedora does, at the very least, mean feature complete and minimally tested.

    • by bill_mcgonigle (4333) * on Friday January 04, 2013 @01:32PM (#42477127) Homepage Journal

      They should never have merged in the new Anaconda in the state its in.

      This looks to me like a failure of release management. Look at the "Contingency Plan" [fedoraproject.org] for the new anaconda UI. They basically said, "we don't have one" and the feature got accepted anyway. So, here we are today.

      I don't blame the anaconda guys for finding out that the problem was harder than they thought. That happens.

      But process is an important part of what makes Fedora Fedora - if anaconda is "too big to fail" then the process is broken, and Fedora is broken.

      I hope the management team has realized that next time somebody says, "we can't have a contingency plan because of X," they respond, "we then you need to re-factor X so you can have a contingency plan."

      • I don't blame the anaconda guys for finding out that the problem was harder than they thought. That happens.

        Exactly! I really appreciate the work they're doing. But the people managing the release as a whole should've known better than to do it the way they did.

    • The main reason for the delay is the new installer. As I understand it, the old one had become extremely bloated and it took a lot of work for it to work properly with a new Fedora release. This is the reason for the "no contingency plan". The contingency would be to keep the old installer, but that isn't as simple as it seems. The installer needed to be redone, and the manpower needed to make the old installer compatible with Fedora 18 just wasn't there, so they couldn't do both at the same time. They need
    • by AdamWill (604569)

      "It is basically impossible to create a new LV or btrfs subvolume and install into it."

      Um. No it isn't. Specific bug references, please?

      • by AdamWill (604569)

        FWIW - I just did a fresh install of F18 to LVM, then installed over the top of that, shrinking the LV that was mounted as / in the first install and creating a new LV within the same VG to be mounted as / in the new install. Worked fine. New install boots, the old LV still exists, can be mounted and contains the old install.

        • Bug 860677 [redhat.com]

          I've been watching and trying right along. The last time I tried was with TC 3. I still couldn't make heads or tails of the partitioning GUI, and it still seemed like it was going to erase everything instead of installing into a new partition.

          Admittedly, I've been trying this on a VM which I've used btrfs for everything. So it doesn't test LVM. Maybe that works now. Unfortunately, all the systems I use LVM for are (for me) mission critical. Though I don't suppose there's any harm in firing up th

          • by AdamWill (604569)

            I haven't tried it with btrfs. subvol support isn't entirely complete, it's true. This hardly represents a regression, though, as there was _no_ interactive support for btrfs in f17, we just dropped it out of the installer entirely for that release. Implementing anything close to 'full' btrfs support is a very big job, because it's got so many damn features - it's like writing support for LVM, RAID and a couple of other storage technologies, from the ground up, all at once...

            But yes, it definitely works for

    • by AdamWill (604569)

      "I consider it basic software engineer to never count on a given feature that isn't done (to the point of having had at least some testing) to be available on release. You don't let your salespeople sell it. And you don't announce it. This is something I've always had a lot of respect for Google for. They rarely announce things until they're actually done. "

      This is impossible if you are an open, public project. We can hardly work on a Fedora release with a new installer UI in secret. If we don't make some k

      • This is impossible if you are an open, public project. We can hardly work on a Fedora release with a new installer UI in secret. If we don't make some kind of effort to put out controlled messaging about the new installer UI, the result won't be that no-one knows about it until we're ready, the result will be that instead of controlled, accurate information being released, random, often inaccurate information will show up. Probably as a result of Phoronix taking public mailing list threads wildly out of context.

        For open, public projects you do not merge new features into the mainline until they are reasonably baked. Yeah, people will learn about them far in advance, and that's just great. But you don't announce that they will be part of a release until they're done.

        That code should never have been merged. It was not done. You should've limped along with the old Anaconda for Fedora 18 (which I know would've been something of a blow since you'd been hoping to have it in 17 if I'm not mistaken) and not merged the new

        • by AdamWill (604569)

          The problem with that is that it's a very difficult call to make. It's pretty much _always_ the case that something isn't done. At some point, you _need_ to have the New Shiny in main where everyone is paying attention to it and testing it and hacking on. You can only get so much work and testing done on a major component in a side branch.

          Personally I think it might possibly have worked better to put off the merge till F19 or schedule a longer F18 cycle, but at the same time, I don't think you can reasonabl

          • by AdamWill (604569)

            also note that the anaconda team is small. If we'd gone ahead with F18 with oldUI, very little work would have been done on newUI between F18 Alpha and Final, because the anaconda team would inevitably have got sucked into the usual round of blocker fix work. So it might have resulted in newUI being delayed not to F19, but to F20...etc...etc...every release we went with oldUI made a _significant_ dent in work on newUI.

    • I asked a dev why the new Anaconda UI wasn't developed separately and then rolled into the next available release whenever it was ready. The answer: Installers have to be developed in conjunction with whatever it is that they're installing. The requirements and dependencies are such that going it alone won't work.

      That makes sense. But, I think some fundamental UI design commitments were made early on that are biting them now. Particularly the manual partitioning interface. I find it just plain difficult

It is impossible to travel faster than light, and certainly not desirable, as one's hat keeps blowing off. -- Woody Allen

Working...