The vast majority of the packages in Ubuntu (more notably in the LTS releases) are all custom patched by Ubu-devs. Rather than taking the raw package and pushing it through, they have a semi-opaque method of testing, patching, and then releasing to the greater community.
I've tried several times to get an 'in' so that I could help with the process, but it seems to me like a 'club hangout' where outsiders are slightly discouraged. :(
I think this is an unfortunate perception. There's an active sponsorship queue, and nominated people run shifts to review and accept outside contributions. All contributors need to do is submit a suitable diff, and subscribe the sponsorship team to the bug. See https://wiki.ubuntu.com/SponsorshipProcess for details.
If you are willing, please help!
Where outside contributions tend to fall down (IMHO) is understanding and thus compliance with existing processes. For example, outside contributors tend (again, IMHO) to underestimate the consequence of regression in stable releases. Or they contribute patches that should really go upstream, and underestimate the extra overhead and community harm of independently maintaining these patches just in Ubuntu.
> Rather than taking the raw package and pushing it through...
The reason is the risk of regression. https://wiki.ubuntu.com/StableReleaseUpdates describes both the process you describe, and the rationale for it.
Where upstreams have sufficient QA and release process to sufficiently minimize the regression risk to existing users of a stable release, an exception can be granted so that the updates can just be pushed through: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExc...
I'll share my story: I help maintain a 3,000+ node Puppet config for a school district, running Ubuntu 12.04 on various laptops/desktops. Part of our config used XFCE's weather widget on a panel. A few months back, the widget stopped working, as the API's url had changed. I had tracked down the issue independently, and even found that newer versions were released for 13.10+, but alas- no backport for 12.04. I tried to investigate how to test and sponsor the package to get it backported for the LTS, but after nearly a day's worth of digging, I gave up.
Conversely, on my Arch tech station, the XFCE widget was updated many times in between, with many bugfixes and other updates.
> The reason is the risk of regression.
I can appreciate it. It makes sense that one would want the software to be as tested and stable as possible.
However, it seems a bit disingenuous to me that the developers of the various software packages are not the 'final say' in the development. Sure, the patches might only affect a specific version of Ubuntu, but as a Developer- I would prefer to fix the issues myself.
I hope that makes sense- I'm not trying to paint Ubuntu's update method in a poor light, I just can't quite grasp the full scope of why it's done that way.
Ubuntu is supposed to integrate and add a QA layer on top of upstream packages. Just pushing any so-called stable release of upstream packages isn't going to improve the situation, even if it might in specific cases.
Personally, I don't see a way out. The very fact that a distro is an agglomeration of independently released packages means that there will be breakages like the ones you describe, because every package has its own concept of stable release, development cycle, feature deprecation, old version support, and so on.
I don't think we purposely discourage people to participate, though I can understand getting lost in the process can be confusing.
So there's definitely a community and it takes time to learn the rules. But there's lots of ways to get involved and if you take the time to understand the issues and then have ideas on how to improve the processes you'll be listened to - Ubuntu is ultimately a community.
You can find out more on how to contribute on the Wiki http://community.ubuntu.com/contribute/developers/
My experiences fixing the resulting brokenness and occasional unbootability is why I first claimed Ubuntu/Debian on my CV.
Looks like the last time files were changed was Sept of 2009. Obviously, I haven't used it since then.
I think it stems from the 'Linux' way of doing things, which is to give as much information as possible, I like it, but I can see how it's off putting to some people.
There's the icon overlay sure, but not a popup or anything.
What is that based on exactly?
Source http://thevarguy.com/ubuntu/rethinking-canonical039s-ubuntu-..., various statements by Mark Shuttleworth, etc.
I'm a proponent of RHEL/Fedora, but still, Ubuntu can upgrade from LTS to bleeding edge fairly easily. Try that with RHEL.
My experience has been to have trouble with both bleeding edges, Fedora or non-LTS Ubuntu. I don't freak out though, as I know the purpose of the bleeding edge is to suffer the bugs so the RHEL/LTS folks of the world don't have to. That said, using a release backward from current for Fedora or non-LTS Ubuntu usually is pretty stable, supposing you're on your game enough to upgrade before repo EOL.
/endrant
Meanwhile, my own experience with the Red Hat family is with CentOS, which is either kept artificially out of date for security reasons ("bleeding edge" is well-named, generally) or else I only ever saw poorly-configured old versions. So I don't know enough to compare it, but I'm comfortable with the Debian family so I'm sticking with Ubuntu.
As a near 100% RHEL/Fedora user I am always wondering if there is anything but a material difference between apt and yum?
From using Ubuntu extensively a few years ago they seem to have near identical feature set?
Apt/dpkg is also a lot more careful about its treatment of configuration files. Debian packages generally ask questions during preconfigure, build a config file, and then run out of the box. But if you already have a config file it will either be left alone or ask you to resolve the merge.
http://unix.stackexchange.com/questions/634/what-are-the-pro...
dpkg -S /some/file # tells you what package provides that file
dpkg -L some-package # lists all the files provided by a package
apt-get search <regex> # lists all package names matching <regex>It's apt-cache search, and it searches full descriptions, not just package names.
As a dev I still love dpkg-buildpackage way more than rpmbuild.
Atleast some of it is momentum from being first. APT was the main reason I jumped ship from Redhat, but that was before yum.