More Backporting Madness: X Server 1.8 To 1.7

[MaestroMaus]

I have one machine that is still running 8.04. I skipped 8.10 because I heard lousy things about it. Skipped 9.04 because I didn't want to do incremental upgrades, and skipped 9.10 for much the same reason, and because 10.04 was just around the corner anyway. Have been looking forward to 10.04 so I could upgrade this older system in a single step and remain on a solid LTS release. But 10.04 is sounding less stable with all the back porting.

My experience with Ubuntu is to always do clean installs. It saves a lot of problems and only takes 45 minutes to backup and install.

[Shining Arcanine]

This could get ugly...
Maybe they should plan on pushing the release date to May or June?

Then they would have to rename it to Ubuntu 10.05 or 10.06, which is not happening. They are set on a 6 month release schedule, where the first number is the year and the second is the month.

Anyway, backporting stuff is a waste of Canonical's resources. They should just upgrade Ubuntu 10.10 to the latest kernel and xserver, recompile their packages around that and be done with it.

[tjaalton]

I've replied to the original ml thread and tried to correct some answer the "questions" shown here..

but I see now that it was not enough:

- this is my own time that's wasted
- yes I know what I'm doing
- it's not a HACKport, but rather upstream code that'll get released RSN
- it's not a bloody mess, they apply rather cleanly on top of 1.7.6
- if it would be accepted that would have to be both for Debian and Ubuntu, not either or
- only a handful of the X11 packages have a real diff between D & U, rest are pretty much in sync

there, that should cover it, for now

[mendieta]

I've replied to the original ml thread and tried to correct some answer the "questions" shown here..

but I see now that it was not enough:

- this is my own time that's wasted
- yes I know what I'm doing
- it's not a HACKport, but rather upstream code that'll get released RSN
- it's not a bloody mess, they apply rather cleanly on top of 1.7.6
- if it would be accepted that would have to be both for Debian and Ubuntu, not either or
- only a handful of the X11 packages have a real diff between D & U, rest are pretty much in sync

there, that should cover it, for now

Timo:

Your work is greatly appreciated, at least by me Many times people take for granted volunteering time from awesome folks who are using their spare time to give others free software.

At the same time, I think it is in everybody's best interest if people express their opinions respectfully in terms of how we can do things better next time (we can always improve). And this is what I meant to do a few posts above I'd love to know your opinion, actually.

Cheers!

[tjaalton]

Timo:

Your work is greatly appreciated, at least by me Many times people take for granted volunteering time from awesome folks who are using their spare time to give others free software.

well it's partly paid time since this would help my work as a sysadmin

At the same time, I think it is in everybody's best interest if people express their opinions respectfully in terms of how we can do things better next time (we can always improve). And this is what I meant to do a few posts above I'd love to know your opinion, actually.

Cheers!

Selective backporting gives the best of both worlds; new features on top of a stable base. Xserver 1.7.x has been great, but a prerelease for most of the release cycle would've meant a lot more pain than what some backports might cause.

[Bryce Harrington]

The amount of backseat driving that occurs on this forum is crazy.

Timo posted a proposal to the ubuntu-x@ mailing list. So far, no one has replied giving any feedback on his proposal. (I've shared my own thoughts directly with him.)

If you have legitimate, well-considered feedback, then join the ubuntu-x@ list and give the feedback officially. If not, well...

Also, several posts are complaining about how "Canonical wants to backport a bunch of stuff which diverges from upstream making things harder to support" etc. First off, Timo is a Debian developer as well as a highly respected Ubuntu community member and his proposal is to take code already existing upstream and get it into both Debian and Ubuntu. In other words his proposal is aiming to do exactly the opposite of what people are complaining - erasing a difference in X configuration between upstream, Debian, and Ubuntu and making things MORE consistent and easier to support all around for everyone.

If his proposal is NOT taken (which given the lateness of things is a possibility) then it means there will be one approach for configuring devices unique to Lucid and Squeeze via udev rules, and an entirely different incompatible way 6 months from now. This isn't catastrophic (for the most part, people don't really need to do this sort of configuration, it's just corner cases), but X.org upstream has been changing how configuration is done ever 6 months, which means having to rewrite docs and tests and patches each Ubuntu release. Timo's thinking is, why not skip the udev config phase and hop to upstream's new configuration approach and save everyone the trouble of having to do a transition between Lucid and Lucid+1.

[Bryce Harrington]

I'm seeing a weird meme here in this forum of "backporting is bad". It seems like people believe that by backporting some stuff to a given release, it makes that release less stable, and that moving to a newer release would gain more stability.

This is patently false. See Dave Airlie's post earlier in this thread. I don't know where you guys get such ideas. The truth is the opposite.

The way backporting works is, you have two sequential versions of a codebase (usually the release and the unreleased git development branch). The newer git code contains some bug fixes and some new features, but also introduces some new bugs and regressions. Since this code is newer than the stable release, it's gotten less testing than the released code so it's bugs are less well understood.

So what you do is you take the stable release with its already known bugs and you selectively pull in fixes from the newer code. The art is to pull the fixes (and particular needed features) without pulling the newly introduced bugs. To do that requires good code review and testing processes. Sometimes you don't have the manpower or time to do QA for your distro, in which case just sending bugs upstream and getting the latest upstream stuff may make sense (as it has proven to be with drm*). If you *do* have the manpower, though, it can result in a much more stable product than you'd have otherwise. We've got about a dozen experienced people involved in Ubuntu's X.org QA for this release which I think is ample.

Anyway, this is all Software Productization 101 type stuff, like Dave points out.

* - as an addendum, to those complaining about Canonical pulling the .33 drm as somehow making it harder to upstream bugs, it is not true. In fact, this strategy was specifically recommended to Ubuntu *by* upstream developers who said that this was the most sane solution and would both solve a bunch of bugs we already knew about (it did) and make it *easier* to upstream new bugs to them. This was not a step taken lightly, and involved a lot of analysis and testing within the Ubuntu-X team before we went ahead with it.

I am quite happy with how things are turning out with Lucid. In general we've tried to be conservative, but at the same time we've taken some aggressive risks in some areas, like moving to KMS across the board, dropping HAL, switching from -nv to -nouveau, moving from .32 to .33 drm. While there are still some bugs to work out, I think these were good choices and our testing seems to be proving it out.

But you might disagree, in which case I offer you this challenge: Get involved. The Ubuntu-X team is an open team with strong collaboration between Canonical and community members. Indeed a lot of the above got done *because of* hard work by community volunteers. If you know X and want to influence Ubuntu's future X.org choices - or if you don't know X but have time and want to learn - it's easy, just pitch in. We don't bite. Well, not much.

[Remco]

Thanks for the explanation. That cleared up my confusion about the bug reporting.

[Hephasteus]

Thank you for sharing your thoughts Bryce. We're not really back seat driving here just trying to figure out things outside of the loop because the loop is busy. I've been watching very closely the changeover from HAL to udev. It's been a good one. It's been fun watching udev be able to gain more and more control and configure itself to the hardware better over the last 6 months. Makes reading the system logs fun except for the latest wall of text from simple greeter. LOL

Hope you get UDEV in place and working for LT release and hope it gets downloaded a hundred million times. Thank you for everything you do for open source.

[TemplarGR]

Backporting IS bad. Of course if you are involved in it, you can provide excuses all the time.

First of all successful backporting takes too much resources. I am not sure if Canonical is able to provide them. My experience with Ubuntu's recent releases was mediocre. Too many bugs, some of them critical. Don't give me the automated response "did you file a report/provide a fix?". I didn't. And you know why? Because i don't care to support a closed ecosystem, get involved in fixing issues for Ubuntu-only. Plus i believe that when someone boldly states there are enough experienced developers overlooking the code, there shouldn't be any serious problems left for example 3-4 months after release right?

Why not spend those resources on upstream projects?Why not test Lucid using kernel 2.6.33 and xserver 1.8? Do you honestly believe that you need fewer resources to backport and test stuff from newer kernels than simply using them? Of course there will be more untested features, but the amount of resources needed will be pretty much the same. Plus you will have the benefit of closer connection with upstream AND newer features. If you really need the stability of older code, then simply use it unchanged and assign your resources for bugfixing.

Of course i am speaking in general about backporting and not so much about this specific issue.

I will give an example from my personal experience:

I am an Arch user. As most probably now, Arch is propably the most up to date and vanilla distro available. But i use Ubuntu as a newbie-friendly distro for other people.

For me, Arch is perfectly stable. Even with git radeon drivers. No screen corruption, no crushes, NOTHING. It simply works, and many times i am amazed that such a bleeding edge distro is so much stable. Newer than Fedora and perhaps more stable than Debian. It ended my personal distro hoping for sure.

But my girlfriend needs an easier distro so i installed Ubuntu 9.10 on her laptop. She used the nvidia blob. Her machince freezes at times, she experiences screen corruption, missing icons, and application crushes at random. By simply triyng to surf the web, read some pdf and write some docs. All this 3 months after release.

Ubuntu software is already old, even for non critical apps. Transmission for example. Firefox. 2.6.31 kernel and 1.6.4 xserver. One would think that those supremely talented ubuntu devs would provide some fixes for those things. They didn't. And Arch, a completely community based distro, smaller than Debian, provides a bleeding edge AND stable experience.

For me, Arch is the living proof that not messing with code and simply staying close to upstream, provides a better experience overall, and with minimum effort. I have experienced this myself, and no matter how many excuses Canonical stuff make i don't care.

I am curious. If ever an Arch-based n00b friendly distro(like Chakra) becomes succesful, if Ubuntu will stay relevand even with Canonical's financial backing...