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

[k1l_]

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.

[Victoria0129]

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

[omer666]

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.

[bug77]

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.

[AdamW]

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 (test@ and devel@) every day. At this point in time we mostly do milestone releases at all for the sake of the publicity.

[AdamW]

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.

[bug77]

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.

[bridgman]

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.

[AdamW]

That's what you call it. The rest of us are looking at how Canonical does it (i.e. they set some dates and stick to them) and then decide you're just delaying

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.

[pal666]

The rest of us are looking at how Canonical does it (i.e. they set some dates and stick to them) and

release piece of shit