That's actually something that was brought up here... about the new firefox + whole KDE thing
2 different suggestions: 1) work like backports.org 2) pin to dapper/breezy + have an app that unpins things if the user wants them (or sets a higher priority or something) What do you think? John Dong wrote: > 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.5 or 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* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > 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 > [email protected] > <mailto:[email protected]> > http://lists.ubuntu.com/mailman/listinfo/ubuntu-backports > > > >
signature.asc
Description: OpenPGP digital signature
-- ubuntu-backports mailing list [email protected] http://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
