[Bug 3318] 5.04 updates

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* <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
> 
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.ubuntu.com/archives/ubuntu-backports/attachments/20051101/0aa822fb/signature.pgp