<div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>For LTS releases I agree this is a problem.  I also think Ubuntu is addressing<br>it in a sane way.  Most of the changes included in the upcoming 
6.06.2 are<br>related to supporting newer hardware.  My launchpad-foo isn't up to providing<br>a link, but you can find a link of bugs that are targeted for 6.06.2.<br><br>For non-LTS releases, I'm not convinced there's a sane way to approach this.
<br>I'd be curious if you have a specific proposal.<br></blockquote></div><br><div>I'd say it is definitely an issue with both LTS and non-LTS releases - though it is definitely much more of an issue with LTS releases (and Debian, which has a release cycle approximately the same length as LTS).  I had a couple ideas here with respect to both cases, though...
</div><div><br> </div><div>My idea would be to basically split the existing backports into two categories:</div><div><br class="webkit-block-placeholder"></div><div>1) An "Optional Updates" category, which contains supported release updates that are not installed by default.  This would include high-demand userspace application updates like Firefox 
3.0 (if it came between releases).  It would include some system-space updates, but only for bugfix purposes or hardware support (a new kernel, for instance, or an Xorg video driver).  For instance, issues such as my MacBook's lack of suspend would be resolved here.
</div><div><br class="webkit-block-placeholder"></div><div>2) For all other backports, add an easy way to self-build packages from source in addition to the existing unsupported backports section.  This could be from the unstable release source, or from the proposed "Grumpy Groundhog" section. Basically, one would add the appropriate source repositories into Synaptic, and the latest binary and source releases would be displayed with an option to "build from source" - which would fetch all dependencies etc.  We could even add the option to set compiler flags for advanced users (might get some Gentoo users to switch :)).  I do know apt provides some of this infrastructure (apt-build etc), but it could be tested and integrated.
</div><div><br class="webkit-block-placeholder"></div><div>I know this may be a completely unfeasible idea, but it is what I was thinking of within the current release cycle.  IAJALU (I Am Just A Lowly User), though...</div>
<div><br class="webkit-block-placeholder"></div><div>Tim</div><div><br class="webkit-block-placeholder"></div><div>P.S. Honestly, my preference would be for a slightly different release cycle.  Each LTS release would be based off Debian stable (and would come slightly after said Debian stable), and each succeeding release would be based off the LTS with backported updates (
i.e. we'd pull new versions of Firefox, the kernel, etc in, but  we wouldn't update glibc just for the sake of updating glibc.  Updates to be incorporated in the next release would be backported on a rolling basis in the "Optional Updates" category.  This would seem to result in more stable releases while making Ubuntu more compatible with Debian. IANAUD, though...
</div><div><br class="webkit-block-placeholder"></div><div><br> </div>