Announcement

Collapse
No announcement yet.

Fedora 25 Not Scheduling A Mass Rebuild Is Raising Some Concerns

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

  • Fedora 25 Not Scheduling A Mass Rebuild Is Raising Some Concerns

    Phoronix: Fedora 25 Not Scheduling A Mass Rebuild Is Raising Some Concerns

    With FESCo having decided not to schedule a mass rebuild for Fedora 25 due out at the end of the year, some developers are unhappy and feel its sacrificing quality over trying to push out a release on time...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #3
    Just to clarify, the lack of a mass rebuild was decided upon months ago and unfortunately was improperly communicated. (It was unintentionally left on the official schedule page and no one noticed this until recently). The "controversy" is essentially due to the fact that its presence on the official schedule led some groups to incorrectly assume that the mass-rebuild was still going to be performed.

    This is not the first time that Fedora has opted not to perform a mass-rebuild. Contrary to the opinions of certain vocal members of the mailing list, this isn't a speed-vs-quality decision. A mass-rebuild is not a guarantor of quality: it's really useful only to take advantage of new features in the compiler. This is a speed vs. new feature situation: FESCo feels that having Fedora deliver twice a year is more valuable to the project as a whole than necessarily delivering everyone's pet feature in Fedora 25. It's not as if there won't be a Fedora 26 right around the corner (which is the whole point of having two releases a year... so people don't have to wait a long time for the features that missed the boat on the previous release.)

    Honestly, this wasn't controversial back when it was proposed and approved months ago. The real issue here is that the communication was mishandled and our official reference pages didn't match the decisions an announcements that we had made.

    Comment


    • #4
      I'm just wondering: why can't you do a 9-month release cycle? Is that too long, even for an in-between mass rebuild?

      Comment


      • #5
        Reading about Fedora and delays/scope creep is just like reading about Adobe patching yet another critical vulnerability in Flash Player.

        GraysonPeddie The challenge is about being unable to do time-based releases. Whether you peg the release date at 6 or 9 months won't make any difference. And they don't have the balls to officially turn Fedora into a feature based release either. If this didn't exist: https://fedoraproject.org/wiki/Releases/24/Schedule , no one would have a reason to complain. We'd just follow their bug-tracker, git or whatever to see when there's something incoming.
        Last edited by bug77; 03 May 2016, 10:33 AM.

        Comment


        • #6
          Originally posted by bug77 View Post
          Reading about Fedora and delays/scope creep is just like reading about Adobe patching yet another critical vulnerability in Flash Player.
          Out of curiousity, what kind of scope creep are you talking about? Honestly it doesn't matter if delays happen, as long as blocking bugs get fixed and are prioritized over getting a release on time. I'm not sure how this relates to flash.

          Comment


          • #7
            Originally posted by Mystro256 View Post

            Out of curiousity, what kind of scope creep are you talking about? Honestly it doesn't matter if delays happen, as long as blocking bugs get fixed and are prioritized over getting a release on time. I'm not sure how this relates to flash.
            Well, now there are voices asking for package rebuilds. F22-23 or so were delayed because of the installer. And generally speaking, developers seem unable to cut buggy features from releases.

            Now don't get me wrong, Fedora is a fantastic piece of work. But for all their technical prowess, I cannot understand how the developers can't figure out how to do proper time-based releases. (I actually do, I just don't like the answer )

            Edit: Oh and it relates to Flash in that you can bet money on both: Fedora being delayed and Flash being in a sorry state.

            Comment


            • #8
              I've never worked anywhere that consistently delivered software on deadline, and none of my employers have to deal with the sheer amount of code that the Fedora team does. I think expecting them to meet projected dates is absurd - they would either need to ship garbage, or fall much further behind upstream projects.

              Comment


              • #9
                Originally posted by bug77 View Post
                But for all their technical prowess, I cannot understand how the developers can't figure out how to do proper time-based releases. (I actually do, I just don't like the answer )
                There's no such thing as a proper time-based release. Fedora follows a plan of "as close to the published schedule as possible, with slips when necessary". We distinguish ourselves from certain other prominent distributions in that way: When Fedora releases, you can be pretty darn confident that it won't have any horrible system-breaking bugs involved. (That's not to say that your pet edge-case will always work, of course). A lot of strict time-based distros prioritize their date over their quality. Fedora tries to take a balanced approach.

                Also, our schedule *is* fluid. We have in the past extended cycles to nine months (or more, in the case of the 12-month cycle to the first Fedora.next release), but we've discovered that six months really is the "sweet spot" for releases. It allows us the ability to maintain a release for about 13 months: much longer than that and what we've learned is that most modern upstream projects (meaning upstreams that appeared post 2010 or so) don't maintain their older branches much past a year. This means that the Fedora Project package maintainer has to do one of two things: 1) manually backport any serious bugs to the old version or 2) try to move to the newer version. In many cases, 2) isn't an option because of compatibility breakage.

                Switching to a nine-month schedule introduces would mean that either we would have to maintain packages for 19 months and face those backport issues or else decide to tell users they must update at every release and only support it for 10-11 months. Furthermore, it would mean a longer time between release vehicles for new features. Right now, if something doesn't quite make the cut (like our plans for a new LiveUSB installation tool), the next Fedora release is still on the near horizon. Start adding extra months to that and the Law of Unintended Consequences means that groups will start trying to shoehorn incomplete code into the release rather than accepting the delay and getting it right a few months later.

                Comment


                • #10
                  Originally posted by bug77 View Post
                  If this didn't exist: https://fedoraproject.org/wiki/Releases/24/Schedule , no one would have a reason to complain.
                  There's also this: https://fedoraproject.org/wiki/Fedor...ase_Life_Cycle which clearly states that:

                  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
                  So, if you just read the schedule you might be lead to believe that it has slipped and that's bad, but if you read how the schedule is created and maintained then it's just perfectly normal and part of the usual development cycle.

                  Not sure why I have to keep remembering people about this when I don't even use Fedora. Oh wait, maybe it's because of all the click-bait articles like this one.

                  Comment

                  Working...
                  X