> 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...
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 suppose I misspoke- I wouldn't say it's discouraged, but as another comment said; it's painfully bureaucratic- it's almost too difficult for an 'average joe' developer to hop in and help patch/test their own software.
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.
Two things: one, the quality of "developer released" packages varies wildly, so it's hard to make a global policy. Two, a distro means integrating many packages. An upstream package change might be 100% reasonable and at the same time break existing users because (e.g.) of a feature removal that went through a normal deprecation policy for that package, that distro users are obviously not aware of.
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 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...