Kubuntu Updates Policy

[Andreas Wenning]

Agreed; this is the way to go from my point of view as well!

We should try very hard to get 3rd digit KDE-releases in -updates; or 
alternatively in -backports if we hit regressions like the rss-reader problem 
in 4.2.3/4 (not suitable for updates due to regressions; but will be an 
improvement for a very large part of the userbase).

Regards, Andreas
-- 
 ,-¤.  Kubuntu Linux
¤    ; http://www.kubuntu.org
 `-¤'  Linux for Human Beings

On Friday 25 September 2009 16:56:41 Roderick B. Greening wrote:
> All sounds reasonable to me
> 
> > I have an outstanding action to draft an updates policy for Kubuntu and
> > take it for the tech board for approval.  The two questions are what to
> > put in -updates and what to put in -backports.
> >
> > Historically (before Hardy), Ridelll used to publish updated KDE version
> > updates outside of the Ubuntu infrastructure.
> >
> > In Hardy, we put KDE 3.5.10 first in backports and later in updates. IMO,
> > it went OK, but took a lot of work to get through regressions.  We also
> > backports Qt 4.4 to Hardy and it did not go well (lots of problems with
> > non-KDE apps).
> >
> > For Intrepid, we released with KDE 4.1.2 and put 4.1.3 and 4.1.4 in
> > updates (via proposed of course).  We also put 4.2.0 in backports.  All
> > of this went well and we had very good upstream support for dealing with
> > regressions in the point releases.
> >
> > I think we mostly expected this to be the model for the future.
> >
> > In Jaunty, we got a bit cross-threaded between Qt and KDE expectations. 
> > Qt expected Qt 4.5/KDE 4.2 and KDE expected Qt 4.4/KDE 4.2.  As a result,
> > we have some minor regressions that are not supported by upstream. 
> > Currently updates are limited to PPAs.
> >
> > We know that KDE 4.4 will be developed with Qt 4.6.  These will be our
> > targets for 10.04.
> >
> > Based on the experience with backporting Qt 4.4 in Hardy, I am convinced
> > backports of 2nd digit updates of Qt is a bad idea.
> >
> > Based on the experience with 4.1 and 4.2, I'm comfortable with pushing
> > 3rd digit KDE updates to proposed/updates as long as we have upstream
> > support.
> >
> > I think that given the pace of Qt/KDE updates it will be rare to have a
> > good mix available for backports.
> >
> > Here is what I propose:
> >
> > New KDE versions (e.g. 4.3/4.4) only in PPAs.
> >
> > Micro-version updates for KDE to -proposed/updates if we have upstream
> > supoort (we did for Intrepid and will for Karmic/Lucid and do not for
> > Jaunty).
> >
> > Micro-version updates for KDE to backports otherwise.
> >
> > No backports of major Qt updates.
> >
> > I think we need to do some experimenting with the idea of micro-version
> > Qt backports.
> >
> > The backports aspects of this don't need tech board approval.  I'd like
> > to push KDE 4.2.4 to Jaunty backports ASAP  and then look at giving Qt
> > 4.5.2 a go.
> >
> > If people generally agree with this approach, I'll draft up something for
> > tech board approval for 4.3/4.4 in updates for Karmic and Lucid.
> >
> > Scott K
> 
> _______________________________________
> Roderick B. Greening, B.Sc.
> Paradise, NL Canada
> E-mail/MSN: roderick.greening at gmail.com
> LP: launchpad.net/~roderick-greening
> Wiki: wiki.ubuntu.com/rgreening
> Blog: roderick-greening.blogspot.com
> Twitter: twitter.com/rgreening
> Identica: identi.ca/rgreening
>