Let's Discuss Interim Releases (and a Rolling Release)

Scott Kitterman ubuntu at kitterman.com
Sat Mar 2 00:13:39 UTC 2013

On Friday, March 01, 2013 03:18:26 PM Steve Langasek wrote:
> On Fri, Mar 01, 2013 at 01:31:37AM -0500, Scott Kitterman wrote:
> > David Henningsson <david.henningsson at canonical.com> wrote:
> > >On 03/01/2013 05:55 AM, Scott Kitterman wrote:
> > >> On Friday, March 01, 2013 05:50:35 AM Martin Pitt wrote:
> > >>> For those we'll need temporary staging areas which are not put into
> > >>> the RR yet until they get a sufficient amount of testing; these
> > >
> > >could
> > >
> > >>> be "topic PPAs" which interested people would enable and develop in,
> > >>> which get landed into the RR when everything is ready?
> > >> 
> > >> For people or teams that are largely or entirely !canonical, this only
> > >> works if all you care about is x86 (i386/amd64).  Anything for armhf
> > >> (or powerpc) would have to land untested since the PPAs that are
> > >> available for !canonical don't build these architectures.
> > >
> > >From what I've heard, that is already fixed, at least for armhf - see
> > >http://dev.launchpad.net/CommunityARMBuilds
> > 
> > Not really.   Look at the limits associated with that.  It's a miminally
> > useful small scale capability.
> > 
> > Also, since it's (AIUI) virtualized, packages built in one of these PPAs
> > aren't suitable for copy to the primary archive.
> > 
> > It's a step, but not a solution.
> If being able to build everything in virtualized ppas with armhf support
> would help solve the release issues for Kubuntu, I believe there's room for
> giving Kubuntu a bigger chunk of time on the virtualized builders.
> AIUI, there are several issues at present that would prevent Kubuntu staging
> its builds of the 6-month KDE releases in ppas:
>  - Kubuntu's build requirements would exceed the advertised community usage
>    limits for virtualized armhf ppas
>  - KDE doesn't build under current qemu due to qemu bugs
>  - Binaries can't be copied from virt ppas to the archive, so rebuilds would
> be required when promoting
>  - It's not clear if there's a ppa schema that would meet the Kubuntu
>    community's needs, or what that schema would be
> Does that sound accurate?
> None of these issues seem insurmountable to me; if the Kubuntu devs decide
> this is the right way to go, I don't think it's out of reach.

First, a disclaimer: While we've been discussing this topic within the Kubuntu 
development team, there's certainly no consensus about exactly what our needs 
are and how we would want to move forward if a near-term decision to abandon 
the current development model for this new proposal were taken.  So this is my 
view, I'm sure others in kubuntu-dev will have different ones.

It does sound accurate as far as it goes.  There are two related, but distinct 
sets of issues:

1.  How to we land major new versions of the packages we focus on into a 
rolling release without significant disruption to the user experience.  With an 
appropriate PPA structure, this would be easily accommodated as a natural 
extension of our current processes.  We'd need to decide policy for when to 
move things from the staging PPA to the rolling archive and I'm concerned that 
waiting too long will compromise the amount of user testing we get and moving 
too soon will compromise the stability of rolling.  From a technical 
perspective, this is not difficult though.

2.  How do we deal with releasing Kubuntu.  I am of the opinion that having "a 
release with the current KDE shortly after it's out" is a significant part of 
Kubuntu's reason for existing.  LTS + Rolling just does not satisfy that.

As I've mentioned elsewhere in one of these subthreads with my ~ubuntu-
backporters lead hat firmly in place, delivering major new versions of KDE and 
required KDE support appliications is not an appropriate use of backports.

Ideally, I'd like to be able to have some way to continue to do a release of 
LTS + Kubuntu packages (KDE and a few related packages) as a Kubuntu release.  
I haven't come up with an ideal approach to do this, but it might be LTS + a 
version specific PPA.  It might be an LP derived distribution.  I really don't 
know how best to approach it.

Scott K

More information about the ubuntu-devel mailing list