6

Reportedly, Debian devs need to squash 54 bugs more. These are termed as 'release critical bugs'. My question is,

if this bug-squashing takes this much time, then how come Ubuntu releases each version in such a short time?

I mean, how do they squash the bugs in this time period? And if they really do, then why doesn't Debian get the debugged code from Ubuntu? Shouldn't these "release critical bugs" be debugged by now? Since Ubuntu uses Debian's testing/unstable as base, and then make their release; and obviously Ubuntu doesn't release a buggy version. It just doesn't make sense to me.

serv-inc
  • 620
  • 5
  • 15
  • 6
    "Obviously Ubuntu doesn't release a buggy version" — oh really? – hobbs Mar 09 '15 at 06:14
  • 1
    Of course Ubuntu releases contain some bugs, which aren't uncommon. But severe bugs are squashed beforehand of the final release, aren't they? –  Mar 09 '15 at 07:00

3 Answers3

12

The release process between Debian and Ubuntu is very different. Ubuntu releases are based on a time schedule (set release date), while Debian uses a "when it's ready" model.

Here are some key points that make a difference in release speed:

  1. Most packages Ubuntu pulls in from Debian are not officially supported (universe repository)
  2. Ubuntu supports 2 architectures while Debian supports 13 (some release critical bugs are specific to an architecture)
  3. Ubuntu does not have a direct concept of a "release critical" bug, although it does have a "critical" bug severity
  4. Only every 4th Ubuntu release (LTS) is recommended for production use.
jordanm
  • 41,988
  • 9
  • 116
  • 113
  • "Ubuntu supports 2 architectures while Debian supports 13 (some release critical bugs are specific to an architecture)" this makes most sense to me. –  Mar 08 '15 at 17:26
  • 5
    One more key point: Ubuntu actually has salaried employees to handle this kind of thing. Debian does not, so you're waiting for when their all-volunteer team gets around to it. – Adam Katz Mar 08 '15 at 22:40
5

As jordanm has pointed out, the release cycles are different: Ubuntu releases every April and October, come what may, whereas Debian releases when testing is ready to become stable, as determined by the release team (based partly on the release-critical bug-count).

There is another huge difference: Canonical employs people to support the core of Ubuntu, whereas Debian has no infrastructure to pay for people to work on its distribution. Some people do work on Debian as part of their job, but there is no way for anyone in Debian to order Debian contributors to work on anything particular, including fixing release-critical bugs. So no-one can say "fix these by such-and-such a date, or else!" (On the other hand I think most Debian developers would like to get the release out, so...)

The release-critical bugs which still need fixing at this stage are mostly complex bugs, difficult to reproduce, difficult to fix and/or difficult to verify. These can be particularly de-motivating for volunteer contributors; it can be hard to justify spending dozens of hours in some cases working on a bug which doesn't even affect the person fixing the bug.

(Before anyone nit-picks, there is now infrastructure in place to pay for Debian developers to work on Debian LTS, but that doesn't contribute to getting a new release out.)

Community
  • 1
Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
0

First, because Ubuntu can (and should) pass their bugs "upstream". Second because Debian's branches are more defined then Ubuntu. There are more steps to mark a bug finished in Debian then in Ubuntu. Most importantly, Ubuntu is a "downstream" release. Meaning that they can get all the bug fixes Debian has so that they can focus on other bugs, where Debian effectively is fixing Debian bugs and Ubuntu bugs.

For example a bug in foo.deb in Ubuntu, gets marked "upstream" and needs to be fixed by Debian. A bug in bar.deb is something that needs to be fixed in Ubuntu and Debian. The Ubuntu team can ignore foo.deb and focus on bar.deb while the Debian team needs to work on foo.deb and bar.deb.

Another example is release cycle. Ubuntu's release cycle is much simpler then Debian's. For example it's not odd to have a package in Debian stuck in "unstable" for 6-12 months or longer before going to testing. Then spend another 6 months in testing before hitting "stable". For debian this is great because you can run mission critical servers on Debian stable and not have to fool with it. Running A mission critical server on Ubuntu is less desirable (even LTS releases) because they are known to be less stable and more problematic. But that distinction usually doesn't matter for smaller servers or desktops.

coteyr
  • 4,280
  • 16
  • 24
  • 3
    Your description of package migration in Debian is wrong. The only way for a package to get stuck in unstable for longer than the standard migration is if it has release critical bug (or a package it depends on is not in testing for that reason). Packages do not directly migrate from testing to stable, that only happens when testing *becomes* the next stable. – jordanm Mar 08 '15 at 17:19
  • The only way packages in testing become stable is when the stable symlink on the mirrors is moved to point at the branch testing used to point at. E.g. it only happens upon release and at no other times. – casey Mar 08 '15 at 23:45