Well, Fedora 14 Will Not Ship On Time

[phoronix]

Phoronix: Well, Fedora 14 Will Not Ship On Time

Besides features like SystemD replacing SysVInit and a much faster JPEG compression/decompression library, one of the other proposals for Fedora 14 was to actually ship it on time. Red Hat's Fedora project has had a poor track record lately of shipping their alpha, beta, and final releases on time and none of the past five releases at least have actually made it out on their due date. John Poelstra, the Fedora Program Manager, sought to change this with Fedora 14, but the entire release schedule has already slipped...

http://www.phoronix.com/vr.php?view=ODUwMQ

[sirdilznik]

No surprise here, this is pretty much standard for Fedora the last couple of years. Pushing the release schedule back a week or even two weeks doesn't bother me at all. I'd rather they take the extra time to work out the kinks and put out another great release like Fedora 13.

Now if they start slipping a month or more instead of a week or two, then there's reason to worry.

[MaestroMaus]

No surprise here, this is pretty much standard for Fedora the last couple of years. Pushing the release schedule back a week or even two weeks doesn't bother me at all. I'd rather they take the extra time to work out the kinks and put out another great release like Fedora 13.

Now if they start slipping a month or more instead of a week or two, then there's reason to worry.

100% agreed, it's "good" that counts first, it's "in time" that is a close second.

[Kazade]

100% agreed, it's "good" that counts first, it's "in time" that is a close second.

Yes and no. See, Fedora takes that approach, and Ubuntu has the "let's get it out the door on time and patch with updates" approach. But both are Doing It Wrong.

If you set a deadline, you should only schedule in enough work so you can do it comfortably within that deadline. Slipping a deadline, or rushing it out the door are just two ways of dealing with failing to do what you set out to do.

[deanjo]

Yes and no. See, Fedora takes that approach, and Ubuntu has the "let's get it out the door on time and patch with updates" approach. But both are Doing It Wrong.

If you set a deadline, you should only schedule in enough work so you can do it comfortably within that deadline. Slipping a deadline, or rushing it out the door are just two ways of dealing with failing to do what you set out to do.

This is exactly why openSUSE went back to a 8 month release cycle after a really bad attempt at pushing a rushed release out after 6 months. On that particular release it took the two months for the major issues to be ironed out where in previous and post version that extra two months allowed for better testing and more time to iron out the kinks.

[nanonyme]

Is a few weeks supposed to be a significant delay anyway when we're talking of half a year release cycles?

[allquixotic]

Minor delays aren't a problem, just a confirmation that software takes longer to get right than anyone could possibly imagine (even the people working on it / managing it).

Shipping on time and pushing out patches afterwards -- like Ubuntu does -- isn't a problem either, as long as the system they get on the CD is nominally installable and can connect to the 'net. Bugs preventing an install or preventing network hardware from working, on the other hand, are major enough to delay a release. Not that Ubuntu would.

The biggest problem with release management in the Linux world is the unwillingness to make stable post-release updates that significantly bump the version of the software. In 98% of the cases, major distros just pull in minor fixes here and there for stable releases; they don't consider the possibility that simply jumping to the next version might be better.

There is a middle ground somewhere between fixing a typo in a man page (about what Debian is willing to do post-release) and upgrading from KDE 3.x to 4.x within the release (about what ArchLinux does, or Debian sid, or Fedora rawhide). There are packages that can 100% safely be pulled in from upstream when a major release is made, because the release is made with backwards compatibility in mind, and upstream has their own extensive QA systems. Some key examples include Firefox, OpenOffice, and sometimes, minor releases of GNOME (e.g. 2.26 -> 2.28).

The problem is that most distro people are of the philosophy of "just say no" to upstream version bumps, unless it's explicitly marked as an incremental bugfix-only release (And even then, sometimes they say no). The dialog isn't even opened around the possibility of pulling in more aggressive post-release updates, except in very few rare circumstances (I think Canonical was considering keeping the official Firefox version up to date in the distro).

How do more aggressive post-release updates relate to release times? Well, think about it. If you know that your policy would allow you to do a post-release of Firefox 4.0, would you be so stressed about trying to include it in the initial release, if your release date is just a few days off from the official release of 4.0? The answer, I think, is "no". As a pre-release manager, you would probably say, "meh, let's just ship Firefox 3.6, and release 4.0 as an update when it's ready". But right now, release managers are generally barred from doing this at all with major versions. So they have to decide whether they want to delay the distro for the upstream release date, or just ship the older stable version of the software. This is just not sensible.

I would note, however, that post-release significant updates are definitely not for every package. Fundamental system packages that could break hardware, or are likely to introduce regressions (like the kernel, udev, Xorg, mesa, etc) should stick with incremental bugfix patches. The significant post-release updates should be reserved for flagship user-visible applications, which are determined based on the scope of the distro (a server distro might want to pull apache more aggressively, while a desktop distro might want to track GNOME more aggressively; a general purpose distro would have to evaluate both of these).

And the list is longer than just Firefox and OpenOffice. I would also recommend to aggressively track packages such as virtualbox-ose, netbeans, filezilla, and google chrome (if the distro ships it).

Of course, even with "star pupil" applications, there's a chance that a new version will require a newer version of a library than what is available in the base system. Such a thing would easily be found during testing. If the library has many other users that would potentially be impacted, the decision might be made to make an exception in the opposite direction, and decide that the upstream version should not be pulled. This is fine, too. The point is that the post-release cycle of major distros could really benefit from more eyes handling these things on a case-by-case basis according to an established set of rules, rather than simply saying "no" to all potential upstream releases for convenience's sake.

[V!NCENT]

Phew, I've only read a quarter of Lennart's blog post (which he can easily release in a pocket format book form), but from what I've read so far I can conclude that no matter what happens, you do not want to ship systemd in a bad shape.

If you do then the consequences are so severe, well basically system administration and the entire userspace will be down the drain untill it's fixed, lol.

[SyXbiT]

FYI, there's a mistake in the original post
"Besides features like SystemD replacing SysVInit"

Fedora replaced sysvinit with upstart in Fedora 9.
So, Fedora 14 is replacing upstart with SystemD

[V!NCENT]

FYI, there's a mistake in the original post
"Besides features like SystemD replacing SysVInit"

Fedora replaced sysvinit with upstart in Fedora 9.
So, Fedora 14 is replacing upstart with SystemD

Systemd in itself, however, is actualy a sysvinit replacement. It remains compatible with the sysv scripts and syntax.