This is a static archive of the old Zorin Forum.

The information below may be outdated. Visit the new Zorin Forum here ›

If you have registered on the old forum, you will need to create an account on the new forum.

[STICKY] Why things break on Ubuntu-based distros

Obsidian1723

Fri Sep 09, 2011 4:29:02 pm

Maybe not everyone knows this, but Debian has 3 branches, debian-unstable, which is the newest code, followed by debian-testing, which is the code which has graduated from debian-unstable for further development and testing, and lastly, into debian-stable, which is where Debian releases come from. I personally feel and have long said that the NON-LTS releases are really just betas for the next LTS since it takes so long to get things even halfway right.

All Debian forks get their initial source from Debian and these branches, so Ubuntu's LTS versions come from debian-testing whereas the NON-LTS Ubuntu releases are pulled from debian-unstable. Now as for the forks of Ubuntu, such as Linux Mint and Zorin OS, they too also have this in their family tree and are thus affected as well. That's why on one of my laptops, I run Zorin OS 3.1 (which is based on Ubuntu 10.04LTS) versus running the latest and greatest Zorin OS 5 (which is based on Ubuntu 11.04, a NON-LTS version of Ubuntu).

I've long stated how broken the forced release cycle of Ubuntu is, but this developer below says it in greater detail than I ever have, with what makes sense as a real-world solution: rolling releases

The above words are mine, the ones below are not - BUT I do agree with them and post all of this here so everyone may understand why Ubuntu (and forks of it) are much more broken than say plain old straight Debian is.

A new release process for Ubuntu?
Scott James Remnant

With the nomination period beginning for the Ubuntu Technical Board, big changes like Unity having arrived in Ubuntu recently, and the upcoming UDS for being what will likely be a new LTS release of Ubuntu, it’s as good as time as any to ask big questions about the development process, challenge assumptions, and make suggestions for big changes.
Cadence

The Ubuntu release process is well known, and its developers talk regularly about the cadence of it. A new release of Ubuntu comes out every six months, and each release follows a predictable pattern. I’ve stolen the following image from OMG! Ubuntu’s recent series about Ubuntu Development.

Each developer working on Ubuntu follows this cycle. When Ubuntu 11.10 is released on October 13th, they’ll begin again. After they recover, of course.

First there’ll be a bit of a wait for the archive to be open, this gets quicker and quicker each release but since it depends on a toolchain being built and other similarly fundamental things, it tends to be a period where most people figure out what they’re going to discuss at UDS.

UDS is a bit late for the 12.04 cycle, so the merge period will probably occupy developer time both before and after UDS. This isn’t represented on Daniel’s chart above, but this is the time when massive amounts of updates arrive from Debian; it’s a time of great instability for Ubuntu. At some point there will be an Alpha 1, but you won’t want to try and install that.

Planning for UDS is going to take up some time, and writing up the results of the plans afterwards and turning that into work items. There’s also a UDS Hangover which nobody (except Robbie Williamson, when drafting the 10.10 Release Cycle) seems to like to talk about. Nothing gets done in the week or two following UDS, everybody is too wiped out.

So realistically speaking, development of features for 12.04 is going to start around mid-November at the earliest. And by features I mean the big headline things in Ubuntu; like Unity, like the Software Center, like the Installer. These things are important to get right.

Pretending for a moment that features are developed over the winter holidays like Thanksgiving, Christmas and New Year, you’ve got clear development time until Feature Freeze. The 12.04 Release Schedule isn’t published yet, but I figure that’s going to be somewhere around February 16th after which everyone switches to bug fixing and release testing.

That’s just 13 weeks of development time!
Chaos

So you’re an Ubuntu developer working on features for the upcoming release, you don’t have anywhere near as much time as you’d expect to actually do the development work. What happens if you’re replacing something that works with something completely new? Can’t you just target a later release, and work continually until the feature freeze of that release?

It turns out that you can’t. There is an incredible emphasis on the Ubuntu planning process of targeting features for particular releases. This is the exact thing you’re not supposed to do with a time-based release schedule.

Unfortunately Canonical’s own performance-review and management is also based around this schedule. The Ubuntu developers so employed (the vast majority) have such fundamentals as their pay, bonuses, etc. dictated by how many of their assigned features and work items are into the release by feature freeze. It’s not the only requirement, but it’s the biggest one.

Your new feature is going to take twelve months of development time to fully develop before it’s truly a replacement for the existing feature in Ubuntu. What you don’t do is spend twelve months developing and land it when it’s a perfect replacement.

What you do do is develop it in 12-13 week bursts, which means it’s going to take you roughly four release cycles before it’s ready rather than two. And you land the quarter-complete feature in the first release, replacing the older stable feature.
Consequence

If this were true, you would expect to see new features repeatedly arriving in Ubuntu before they were ready. Removing the old, deprecated feature and breaking things temporarily with the promise that everything will be better in the next release, certainly the one after that, definitely by the LTS.

Maybe you don’t believe that characterizes Ubuntu, in which case you should probably just stop reading now because we’re not going to agree with my fundamental complaint.

But I will say this: I know I’m responsible for doing this on more than one occasion because I had to; and I saw the exact same pattern in others’ work, when I was a manager my reports complained that they had to follow this pattern and I still see the same pattern today with features such as Unity and the Software Center.

Follow this pattern and developers are going to complain that they need a release where they don’t have any features to work on, and can just spend the time stabilizing and bug fixing.

Worse, follow this pattern and you’re going to create a user expectation that releases are going to be largely unstable and contain sweeping changes that are going to be surprising to administrators of Enterprise desktop deployments, and discourage them from using your distribution at all.

A kludge to this would be to overlay a second release schedule onto your first one, with more of an emphasis on stability and support. It’s a target for your developers to complete their features, or at least stabilize them in those 12 weeks; and it’s a target for your users to consider deployment. So three out of four of your releases are really just unstable previews of that final fourth release.
Complacency

This second LTS release cycle solves the unstable release issue, so why is this a problem?

Because developer time is wasted; because user time is wasted; because user confidence is lost.

Because features can take longer than two years to develop; or if even if a feature takes just two years, if it’s not begun immediately after the previous LTS release, it’s not going to be ready for the next one so you might postpone and lose the lead.

Because you might expect a knock-on degeneracy effect in the LTS releases as well; with 12.04 LTS being less stable than 10.04 LTS, which was less stable than 8.04 LTS which was less stable than 6.06 LTS. And it’s far too late now to have considered the 10.10/11.04/11.10/12.04 cycle to have been a Super-Long-Term-Support release and kept back the complete replacement of the desktop environment.

Because the original reason for the six-month cycle has already been forgotten: features are targeted towards releases, rather than released when ready; because the original base for the release schedule (GNOME) is no longer a key component of the distribution; because no other key component has adopted this schedule.

Because these might be a better way.
Cataclysm

What I’m going to suggest here is a completely new development process for Ubuntu, complete with details about how it would be implemented.

I’m going to suggest a monthly release process, beginning with the 11.10 release. It so happens that this fits perfectly with Ubuntu’s version numbering system, the next release would be 11.11, followed by 11.12, followed by 12.01 and so on.

This monthly release would be simply known as release in your sources.list, updates would be published to it on the first week of the month. There would be no codenames, and due to the rapid releases, changes would be largely unsurprising and iterative on the previous releases.

In order to provide user testing, a second release known as beta would exist. It’s from this release that release would be copied from on that first week of the month. beta would be updated every two weeks, on the first week of the month after it became the new release, and then on the half-way point of the month. Users who like a little bleeding on their edge can change their sources.list to use this more exciting release, or download appropriate disk images.

Developers wouldn’t run either of these, they would run the third release branch alpha. It’s from here that beta is updated; and from here that daily disk images would be generated.

Publishing from alpha to beta, and then from beta to release is handled semi-automatically. The release manager will track Release Critical bugs, and will hold up packages from copying from one to the other if they have outstanding problems. If this sounds familiar, it’s because this is exactly how the Debian testing distribution works and I recommend using the same software (which Ubuntu already uses to check for archive issues).

So where do developers upload? It’s tempting to just say to alpha, but if we say that, alpha will end up looking very different from release because it will be filled with unstable software that’s not ready for users yet. This will make it harder for problems in the release branch to be fixed, because none of the components are left in alpha because they’ve been replaced by something that’s not ready yet.

Developers will upload to an unpublished trunk branch. Packages will be copied to alpha provided:

there is a signed-off code review for the upload
the upload meets policy (lintian clean)
the upload builds on all released architectures
unit tests pass on all released architectures
functional and verification tests pass on all architectures for the archive as a whole

I just introduced a bunch of new checks to the developer process there; I just introduced code review, mandatory unit tests and then piled functional tests and verification tests on top.

The first four are relatively self-explanatory; fail any of these tests and your upload has marked the tree red. In which case not only will your package fail to copy to alpha, but you’re about to have a conversation with the Release Manager.

For functional and verification tests, this means doing more automated QA. A failing test could be an automated installer run, or an automated boot-and-test run, etc. They’ll run sometime after the fact and will make the entire tree red. The Release Manager or their team will have to examine the logs to figure out the culprit.

So things aren’t copying to alpha, now one of two things is going to happen.

the Release Manager reverts your upload. Because trunk is unpublished, this is simply overwriting with the older package from alpha; nobody except the original developer is going to have known about it
after talking with the developer, it’s decided that further uploads of other packages are required (e.g. due to dep-wait, or the bug being elsewhere) in which case the tree remains red while the developer (or another in rare cases) prepares that fix upload.

While the tree is red, nobody else is allowed to upload unless it’s a fix for the problem. All effort should go to fixing the tree.

If the archive has to always remain stable, how do you develop large features such as Upstart, Unity, Ubiquity, Software Center, etc.? You use a PPA to do development, on your own timeline.

If your feature takes twelve months to develop, you take twelve months to develop it in that PPA. You’re going to be posting regularly to mailing lists or blogging about your feature to encourage users to add your PPA to their sources.list to gain testing. Obviously you’ll be doing various uploads to the main series over time to get all your dependencies in early where they don’t conflict with what’s already there.
Conclusion

My proposal is a radical change to the Ubuntu Release Process, but surprisingly it would take very little technical effort to implement because all the pieces are already there including the work on performing automated functional and verification tests.

I believe it solves the problem of landing unstable features before they’re ready, because it almost entirely removes releases as a thing. As a developer you simply work in a PPA until you’ll pass review, and land a stable feature that can replace what was there before.

It solves the need for occasional stabilization and bug-fixing releases because the main series is always stable and can receive bug-fixes easily separate to any development work going on. A developer can chose to focus on looking after the main series for some of their time in addition to their feature development work, or devote all of their time to it.

Another problem I’ve not talked about is that of building software on an unstable foundation, also solved by this change. Since developers will run alpha, and vendor developers can just run a relatively up-to-date, yet stable, release branch, software can be built on a solid foundation. Only the new feature or software itself is unstable until ready.

Canonical can keep its review schedule, and use developer uploads and work items; except rather than landing in a release, they can now land in a PPA.

Merges from Debian unstable can be handled pretty much continually as long as they keep the tree green, alternatively one can decide that users ultimately don’t care about an updated version of cat and until a case can be made (e.g. an open bug) for a package’s update, it need not be merged.

Users can now be confident of always receiving a stable operating system, because of the multiple testing and QA passes each change continually receives. Updates come in monthly, two-weekly or dailyish batches depending where in the main series they chose to run.

Enterprise administrators can run this stable release, because it only changes gradually with well-tested updates. The big changes and features have a long gestation period in PPAs, with many advance notices and blog posts about them. They’re not a surprise and can be planned for well in advance of their landing.

Downsides will, doubtless, be found in the comments below.

For your consideration.

Source: http://netsplit.com/2011/09/08/new-ubun ... e-process/

Obsidian1723

Sat Sep 10, 2011 5:03:29 pm

swarfendor437 wrote:Perhaps it's time to jump ship for BSD then which has a two-year cycle before the next stable release!


I use pfSense (FreeBSD-based router distro) on a PC with 2 NICs, and that's my router. BSD is great, but BSD has a much smaller community than Linux does; however, between Linux and BSD, (even with SELinux), BSD, (and specifically, OpenBSD), is the most secure in the World.

Let's not forget, Debian releases every 2 years as well, and is rock effing solid once setup. As far as support goes, nothing beats that of Red Hat, and thus by proxy, CentOS. Change the logos and images in CentOS, and you have Red Hat. For those who like the NON-LTS, bleeding edge of Ubuntu, its' direct counterpart in the Red Hat-based world, is Fedora.

I use Ubuntu for my desktop, Debian and CentOS for servers. All are rock solid stable. I admit that I am more akin to the *.DEB format and Debian-Based distros over the *.RPM and Red Hat-Based distros; but that's just my personal preference.

Use what works for you, but don't rule out the Linux world over Canonical's b.s.

Obsidian1723

Sat Sep 10, 2011 6:07:55 pm

swarfendor437 wrote:I agree about Fedora as I have explained elsewhere on my dabbling with the 'Leonidas' version. But I don't think you can compare Ubuntu with Fedora (unless you are referring to releases that use Unity - then I would!)


I was only saying that Fedora is the counterpart in the Red Hat based distros of Non-LTS Debian0based Ubuntu. This is because like the Non-LTS Ubuntu, Fedora is less stable than CentOS, which would be akin to Ubuntu LTS. (of course Red Hat's counterpart is Debian). I was merely comparing the Red hat side of things to the Debian side of things, that's all.

Wolfman

Sun Sep 11, 2011 8:08:53 am

I agree with Obsidian; Ubuntu should also (IMO) be a "Rolling Release" and not updated every 6 months because they haven't gotten the bugs out of one version, they are busy pushing out the next which will also have bugs on/in it and the forums are full of various questions for various versions when quite simply; a "Rolling Release" would help solve (at least partially) this problem. :D

I tried Fedora 15 recently to see if it would run on a friends notebook but removed it due to the very complicated package manager, update didn't work and each package listed would just baffle a "Newbie" due to overkill in the package lists, they would have a hard time deciding what packages are what because the lists are too long with every single package available being shown in a GUI !! :( .

I didn't like the DE either!!.

Regards Wolfman :D

Wolfman

Sun Sep 11, 2011 3:15:39 pm

Here is an interesting article:

http://www.pcworld.com/businesscenter/a ... cycle.html

They cannot get the twice yearly releases running correctly!!!!!!.

Regards Wolfman :D

Obsidian1723

Sun Sep 11, 2011 3:52:37 pm

Wolfman wrote:Here is an interesting article:

http://www.pcworld.com/businesscenter/a ... cycle.html

They cannot get the bi-annual releases running correctly!!!!!!.

Regards Wolfman :D


"People like to explore" ??? What a load of B***sh*t if I've ever heard B***sh*t before. The average user of a computer (which usually runs Windows) does not like to explore. Now, the argument could be made that if you want to migrate users away from Windows, you give them the same GUI as before. I believe Zorin OS does that with the Aero (Windows 7) and Luna (Windows XP) themes.

Familiarity is good to get people to move over from Windows to Linux, however Linux cannot be "better" than Windows or different from it (at least in looks), if Linux serves only to look like Windows. Regardless of how much Linux can look like Windows, it's totally unlike Windows.

People who want to learn and explore do so in ALL areas of their lives, NOT just on their computers. Some people thrist for knowledge, while others settle for rote memorizations and muscle memory. While I like moving people away from Windows to "stick it to the man", I also realize doing so may not be in the best interest of Linux, it's users, or the people which we are trying to migrate over to Linux. For the people where if one thing doesn't work, "It's broken. It sucks." I'm going back to Windows", or for those people who DEMAND support (and thus need paid support), they really should just stay with Windows. Unity, Gnome3, these are out there because Linux is being dumbed down to the lowest common denominator of user.....the exact type of user who should not (jn my opinion) use Linux.

I've seen the previews of Windows 8, and it has a Unity / smartphone interface to it, so sadly, this is becoming the norm it seems. Such "Fisher-Price" UIs break my workflow. I like Compiz and other eyecandy, but I use my PC to get work done, not look cool. I realize not everyone can drive a stick shift, and for those people, automatics are fine; but for those of us who can, do, want, and need to drive a stick to get the most performance out of our car (aka computer), we resent being forced to drive an automatic. (unity, gnome3)

So, it's Linux. If we dont like it, we can just replace unity or gnome2 with KDE, gnome2, etc, right? Yes, but if I wanted to roll everything myself, I'd just use gentoo and install from source, and for that specific machine, but I don't want to have to do that. I'd rather use my time in other ways that reinventing the wheel from scratch everytime I install it on a system. Also, even if I did do that, gnome2 isn't being supportted anymore, nor does gnome3 really provide an exact duplicate of gnome2, when it should. Gnome3's "Fallback Mode" sorely lacks when compared to actual gnome2.

Linux is at a crossroads really...before its' users were developers, but now, it has a user base who does NOT program or develop, and are merely users. I fall somewhere in the middle as a power user. I want to install my Ubuntu, Zorin OS, etc with gnome2 and tweak it.

So far the only really viable options for gnome2 are to use it in an exsting distro which supports it, but know that no gnome2 updates are going to be made..... or use Ubuntu Gnome Remix, a script slowly being developed which will one day hopefully realease an ISO, or lastly, there is a gnome2 fork called "Mate", but what happens with it remains to be seen. Last time I checked, the website for it was down.

I've used XFCE, Enlightenement, gnome2, and several other DEs, all because I had to explore to find one I liked, which I did with gnome2, so that's fine, but now I find that within the next few years, I';ll be forced to search again, not because I want a new UI, but because gnome3 and unity are becoming the norm. THose of us who like to use gnome2 are left scrambling. If I cannot find a replacement to gnome2, which I hope one is made by someone within the next few years, I'll have to forgoe a GUI alogether and just go back to strictly command line.

Wolfman

Sun Sep 11, 2011 6:21:01 pm

Obsidian1723

Wed Sep 14, 2011 5:51:49 pm

Wolfman wrote:Here is another good read!!.

http://ostatic.com/blog/bacon-justifies ... -decisions

And:

http://www.omgubuntu.co.uk/2011/03/unity/

Regards Wolfman :D


Thanks man. I read link #1 already and agree with it. I'm not a fan of gnome3 or unity for a variety of reasons, many which are posted by other people all over the Interwebz, so I shall not repeat them here.... but let it be known, I share the same rants as many of them.

Obsidian1723

Wed Dec 05, 2012 6:01:22 am

necro boost.

Sorry all, life has been busy. I know this is an old post, but in April 2012 my father passed after a long illness, I was working at a major company and recently left it for a smaller one when I'm not getting training and certifications to work on F5 Networks, and life overall has just been super busy. Priorities, ya know?

Installation of Linux and updating it may be a bit more difficult with not only UEFI, but also the fact that Intel is going to make CPUs and mobos one unit. No more putting your own procs on mobos.

http://www.zdnet.com/intel-preparing-to ... 000008024/

Linuxgamer94

Tue May 06, 2014 3:24:48 am

I don't know, after I tried Antergros. There are two ways they could do it, the arch way, and the debian way. As we all know in arch you get the latest packages, how ever nothing works and that would be bad for ubuntu. How ever there is the debian way that most people copy where you download a snapshot and upgrade from version to version and it is much stabler then arch and its constand rollling. Ubuntu can not handle an arch like rolling release.