John Dong jdong at
Tue Nov 1 14:35:30 CST 2005

Two interesting points have been brought up here about backporting:

(1) Upwards dependency spirals
(2) Unwanted (perhaps) changes for users -- Does the guy wanting a newer
Firefox welcome a brand new version of KDE?

IMO the official hoary-backports repository needs to be ultra-conservative,
making sure not to impact users negatively.

However, at the same time, unsafe foolish updating techniques are worse than
the Backports team working with various Ubuntu officials on producing
quality component updates.
Here comes my opinion on the latter issue:
I believe that 6 months is sufficient turnaround on major component upgrades
-- Most people will not desire a brand new KDE or GNOME until the next
release of the OS. In addition, I believe large changes (like KDE
3.4->3.5or OOo
1.0->2.0) would cause significant upgrading issues that are not acceptable
in a stable release.

However, I do believe that some fixes in point releases should get
"backported" to stable releases. Each point release of KDE or GNOME
addresses countless bugs and side effects. If these can be isolated and
brought back to stable releases, that'd be great. Severe impediments in
functionality (such as Warty's Nautilus FTP client being completely
worthless) should be done via the -updates repository, and less important
changes should be brought in via hoary-backports.

On 11/1/05, Martin Meredith <mez at> wrote:
> I think that the fact that Riddell has managed to "backport" (in a
> slightly different sense of the word) KDE 3.4.1 to hoary etc etc means
> that KDE shouldnt be that much of a problem, espescially for Dapper->
> breezy where we wont have any major changes.
> It's not that hard to do, but i agree... toolchain shouldnt be
> touched... and if it's requied to be touched to upgrade something...
> then it shouldnt be backported
> Matt Zimmerman wrote:
> > On Tue, Nov 01, 2005 at 10:56:08AM -0500, John Dong wrote:
> >
> >>To the Developers listening in (or being spammed to listen in ;-) ):
> >>
> >>What do you feel about \sh's suggestion of "upgrading gnome or kde"?
> >>
> >>Surely that'll take kdelibs or libgnome*, qt/gtk updates and such upward
> >>dependencies.
> >
> >
> > I think it becomes a question of what we want backports to be.
> Currently,
> > my notion is that it is intended to be useful groups of updated packages
> for
> > stable releases which meet the needs of many users.
> >
> > Of course, different users have different needs, and we should think
> > carefully about what we choose to backport. I would say that in general,
> > backporting toolchain components should be avoided because of the
> complexity
> > and instability that can be introduced. Libraries sometimes make sense
> to
> > backport, but this should be considered on a case-by-case basis.
> >
> > KDE and GNOME are large, complex, interdependent sets of software
> packages
> > which could be tricky to backport. This cost should be weighed against
> the
> > alternative of simply upgrading to the next release.
> >
> --
> ubuntu-backports mailing list
> ubuntu-backports at
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the ubuntu-backports mailing list