[Bug 3318] 5.04 updates

On 11/1/05, Martin Meredith <mez at ubuntu.com> wrote:
>
> That's actually something that was brought up here... about the new
> firefox + whole KDE thing
>
> 2 different suggestions:
>
> 1) work like backports.org <http://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?


I like #2 better... #1 sounds too complicated to set up.


Either way, if we go that way there needs to be an app of some sort
(preferably
GUI) for users to choose their Backports.


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* <mez at ubuntu.com <mailto:mez at ubuntu.com>>
> > 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 lists.ubuntu.com
> > <mailto:ubuntu-backports at lists.ubuntu.com>
> > http://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
> >
> >
> >
> >
>
>
>
> --
> ubuntu-backports mailing list
> ubuntu-backports at lists.ubuntu.com
> http://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ubuntu.com/archives/ubuntu-backports/attachments/20051101/65d32ca8/attachment-0001.htm