Announcement

Collapse
No announcement yet.

Sadly, To Not Much Surprise, Fedora 24 Alpha Has Been Delayed

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by AdamW View Post

    Would you prefer we close up the development process and do all the scheduling meetings in private, then only publish the schedule publicly when we're totally sure of it? Because the reason you even know the schedule is changing is that we do it all out in the open so Phoronix can read our IRC logs and then talk about how we're 'delaying' things. We don't *have* to put all this stuff out there, if all we're going to get is rotten fruit for doing it.
    Personally I would prefer if you either:
    - do time based releases and include whatever is ready
    - don't do time based releases and then don't publish dates until you're certain you can meet them.

    Yes, I know, for RedHat Fedora is just some proving ground. Just don't be upset we treat it as such and go with distros that care more instead.

    Comment


    • #32
      Originally posted by bridgman View Post
      It seems to me there are three options:

      1. Be really conservative up front so you can always make your initial goals (ship less than you could have or release early half the time which is almost as bad as releasing late)

      2. Operate on a fixed-time basis and adjust features/quality as needed

      3. Operate on a fixed-content basis and adjust schedule as needed

      From a user perspective I like having some distros operating on fixed-ish-time and others operating on fixed-ish-content, although from a vendor perspective it makes things a bit more complicated.

      Ideally we would have better schedule alignment between all the upstream components that feed into distros, and at that point it would probably make sense for most distros to operate on the same model, but until then it's really a matter of choosing between devil A and devil B.
      Fedora explicitly chooses a hybrid of 2 and 3; we try to strike a balance between keeping to the schedule and releasing something of acceptable quality. Honestly I don't understand why news sites / commenters seem to get so bent out of shape over a 'delay' of like one or two weeks. Does anyone really look at the Fedora schedule when we publish it and say "OK, I'm clearing my schedule for October 3rd so I can spend all day installing a new Fedora release!"? I mean, it's not like the previous release suddenly becomes radioactive the day the new one comes out. I always figure so long as we get the release out within two-three weeks of where we were aiming for, that seems completely fine. It'd be *nice* to hit the exact planned schedule for a release sometime, but it doesn't seem like a big deal when we're a week or two off. I *do* want us to work pretty hard to avoid the F18 kind of cycle, though rewriting anaconda was always going to be a big thing.

      Comment


      • #33
        Originally posted by bug77 View Post

        Personally I would prefer if you either:
        - do time based releases and include whatever is ready
        - don't do time based releases and then don't publish dates until you're certain you can meet them.

        Yes, I know, for RedHat Fedora is just some proving ground. Just don't be upset we treat it as such and go with distros that care more instead.
        It's not a question of 'including whatever is ready'. It's not like you can just hit a button when there's a blocker bug and jettison some part of the distro and make it magically go away. I mean, say the bug is in anaconda; we can hardly get to one week before Final release then say 'oops, we found this bug in anaconda, let's just ship the anaconda from the previous release instead!'. That ain't how software works. It would never fly. You have to actually figure out the cause of the bug and an appropriate resolution for it, every time.

        Distros are huge, complex things with literally millions (probably billions) of unpredictable interactions among thousands of components. Usually the bugs we run into really 'happened' several weeks or months earlier, but you just can't have enough testing - manual, automated, whatever - to catch *everything* the moment it appears. It's too huge a project. So by the time you find the bug, it's not usually the case that you can immediately say "oh hey, all we have to do is roll back X and it'll go away!" Things just don't *work* that way.

        Fedora isn't a proving ground. It's a serious distribution intended for serious use. I work on it full time, so do lots of other people. We care a lot about making it work. That's why we have delays in the first place. If we *didn't* care, it'd be easy to ship on schedule: we could just kick whatever crap came out of the image build machine out the door and say it's done. I mean, we *could* have shipped Alpha on time. No-one drops dead if Cockpit doesn't work out of the box on Server, right? But we set down some quality standards and we decided to stick to them: Fedora is for the moment still an 'all-or-nothing' proposition, we either release the whole thing or none of it, and Cockpit is considered one of the primary interfaces to Server, so if it doesn't work right, we consider that to be a blocker bug. That's what I'd call 'caring', not just sticking blindly to a release date for the hell of it.

        Edit: also, as someone pointed out upthread, it's not like you can't just install Fedora 24 any damn time you want. No-one has to wait for the "Alpha release", or the Beta, or GA. There's an F24 compose every night, it's automatically tested and you can go look at https://openqa.fedoraproject.org/ to see the results for yourself, or you can see them mailed out to the main pre-release mailing lists ([email protected] and [email protected]) every day. At this point in time we mostly do milestone releases at all for the sake of the publicity.
        Last edited by AdamW; 18 March 2016, 05:04 PM.

        Comment


        • #34
          Originally posted by AdamW View Post

          It's not a question of 'including whatever is ready'. It's not like you can just hit a button when there's a blocker bug and jettison some part of the distro and make it magically go away. I mean, say the bug is in anaconda; we can hardly get to one week before Final release then say 'oops, we found this bug in anaconda, let's just ship the anaconda from the previous release instead!'. That ain't how software works. It would never fly. You have to actually figure out the cause of the bug and an appropriate resolution for it, every time.
          Again, I haven't been following every Linux distro, but I'm pretty sure Fedora is the only one that constantly publishes dates and then doesn't meet them. Clearly there's a better way to do what you're doing, only you haven't found it yet.

          Comment


          • #35
            Originally posted by magika View Post
            Also not as fast as Arch (rpm-dnf-slow vs pacman) and not as stable either: I've never had so many things broken due upgrade in Arch as when I did Fedora upgrade, and more, upgrading script broke itself :P
            You must not have been using Arch for too long to say that. There were and there are still very famous breakages with Arch updates, not to mention software migrations requiring manual interventions that can sometimes become tedious. Of course everything is documented and it is a very good way to learn Linux internals and the way it works (or sometimes the way it doesn't).

            Also when you use GNOME or KDE they will more often than not release versions that are not stable yet. Every time I had a desktop environment update it would become almost unusable for 3 weeks.

            Of course it's not their fault and some would argue that it's the DE's fault, but at the same time those need to be tested and Arch is one way of testing it, that's the bleeding edge philosophy. Arch advocates contributing, and is more directed towards users that know how to use gdb and report bugs. Yet again, it's very instructive but not what I would call stable.

            As my free time is progressively going away, I don't have enough time for this any longer. I switched back to Fedora two months ago after some 6 years using Arch.

            Comment


            • #36
              Truthfully, I don't see this as a big deal and don't understand the hate toward the developers. I'd much rather have them keep the quality up and have "delays" as some complain about then have them just release something and say "Well, here you go. It's full of bugs, isn't stable, and well... because a bunch of crybabies wanted it on the original day we thought we'd publish it, you're on your own until it gets fixed." That would be ludicrious. Honestly, cut Red Hat and the Fedora community who are working hard for a quality distro (which still for me reigns supreme) some slack. Personally, I like the fact they care as much as they do. I've switched so many friends over to Fedora who are in their twenties and even have a sixty year old guy using it and all of them tell me they wouldn't use anything else. To me that shows the commitment and quality of the Fedora team. AdamW, if you happen to read my comment, I for one, in my opinion, think you guys are doing a fantastic job and please keep up the good work. Take your time as you always do, those of us who love Fedora will wait. Your releases are always good releases and I for one want to say thanks

              Comment


              • #37
                Originally posted by AdamW View Post

                Would you prefer we close up the development process and do all the scheduling meetings in private, then only publish the schedule publicly when we're totally sure of it? Because the reason you even know the schedule is changing is that we do it all out in the open so Phoronix can read our IRC logs and then talk about how we're 'delaying' things. We don't *have* to put all this stuff out there, if all we're going to get is rotten fruit for doing it.
                Blaming others now is not the right path. And putting development behind closed doors is what RedHat were accusing others of, so that would be double standards, too.

                So either your Release Schedule Setup doesnt work out and needs to be recalculated or your developers are used to having delays and sort of dont care if its some days/weeks behind the schedule.
                But saying we have fixed release schedules, but then having a delay every time and saying "that doesnt matter anyway" just makes the Project look bad.

                Comment


                • #38
                  Originally posted by bug77 View Post

                  Again, I haven't been following every Linux distro, but I'm pretty sure Fedora is the only one that constantly publishes dates and then doesn't meet them. Clearly there's a better way to do what you're doing, only you haven't found it yet.
                  Well, except you're missing the point where you explain why it actually *matters* so much that we're a week or two out from the dates we aim for. Still no-one has said anything about that. You just seem to be taking it as read that everyone agrees it's a terrible, awful thing for us to post some dates and then not hit them exactly, but you're still not saying *why* it's terrible.

                  Comment


                  • #39
                    Originally posted by k1l_ View Post
                    Blaming others now is not the right path. And putting development behind closed doors is what RedHat were accusing others of, so that would be double standards, too.

                    So either your Release Schedule Setup doesnt work out and needs to be recalculated or your developers are used to having delays and sort of dont care if its some days/weeks behind the schedule.
                    But saying we have fixed release schedules, but then having a delay every time and saying "that doesnt matter anyway" just makes the Project look bad.
                    We don't say we have a fixed release schedule. What we say is this:

                    "We say approximately every 6 months because like many things, they don't always go exactly as planned. The schedule is not strictly time-based, but a hybrid of time and quality. The milestone releases are tested for compliance with the Fedora Release Criteria, and releases will be delayed if this is not the case."

                    That's right on the page that defines the Fedora release cycle:

                    https://fedoraproject.org/wiki/Fedor...ase_Life_Cycle

                    We have the schedule because, well, you have to have something to *aim* for. Otherwise we'd wake up every day and go "well, shall we release a Beta today?" and that'd get old pretty quick. But we don't in fact claim that we have a fixed release schedule, we say we have a target and to a degree we will adapt around it as quality requirements dictate.

                    Comment


                    • #40
                      Originally posted by k1l_ View Post
                      So either your Release Schedule Setup doesnt work out and needs to be recalculated or your developers are used to having delays and sort of dont care if its some days/weeks behind the schedule.
                      Or you're making a big deal out of nothing and there's actually nothing wrong with the way Fedora development happens?

                      Originally posted by k1l_ View Post
                      But saying we have fixed release schedules, but then having a delay every time and saying "that doesnt matter anyway" just makes the Project look bad.
                      Where did you get the idea that Fedora has a fixed release schedule? According to the publicly available official Release Life Cycle document, it's a hybrid, so it's exactly what it's supposed to be, nothing more, nothing less, and anything else is your own incorrect and baseless assumption.

                      Comment

                      Working...
                      X