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

[Scott Kitterman]

On Thursday, February 28, 2013 06:38:41 PM Dmitrijs Ledkovs wrote:
> On 28 February 2013 17:16, Scott Kitterman <ubuntu at kitterman.com> wrote:
> > On Thursday, February 28, 2013 12:07:02 PM Jeremy Bicha wrote:
> >> On 28 February 2013 16:31, Scott Kitterman <ubuntu at kitterman.com> wrote:
> >> > This may be true for Canonical and the Ubuntu desktop, but I strongly
> >> > believe it's not the case for Kubuntu.  For me, a Kubuntu release means
> >> > the most current KDE.  I generally run the latest regular release and I
> >> > think that most of our user base does too.
> >> > 
> >> > KDE releases on a regular 6 month cadence, just like Ubuntu has, so
> >> > this
> >> > has worked very well.
> >> 
> >> On the other hand, Kubuntu makes the latest KDE available to the
> >> current stable release through their official PPAs. People that use
> >> that PPA already are effectively running a rolling Kubuntu release. If
> >> the rolling release happens then y'all won't need to maintain that PPA
> >> any more.
> > 
> > Not at all.
> > 
> > While those PPAs are very popular, they are popular because they are new
> > KDE on a stable release.  We probably need more PPAs, not fewer.
> > 
> > For rolling to have consistent quality, that means no more KDE betas in
> > rolling.  So new development work would all have to be done in a PPA.
> > 
> > We'd also need per KDE release PPAs for at least some transitional period
> > for LTS + KDE version.
> > 
> > What that never gets us, however, is a release with the current KDE
> > release
> > more often than every two years.  That's a significant issue that I don't
> > know how to solve without building ISOs from PPAs.
> > 
> > I expect we can manage, but it will almost certainly be more complex, not
> > less, if we are to maintain Kubuntu in a manner that's recognizable.
> 
> I don't think KDE releases aligned perfectly with Ubuntu release, such
> that unlike before one can expect KDE full release to land much sooner
> in the rolling release (straight away) and with more general
> availability within one month. Instead of up-to 6 months (well
> something like 4-5).
> If I am not mistaken there has been in the past cases of shipping -rc
> stacks of gtk/kde and doing 0-day / 1st-week SRUs of the final
> releases. This is, in a way, "on-time" but defeats stability criteria
> for the users.
> KDE stacks have nightly builds and depending on how stable they are,
> one can start uploading them into rolling release at beta phase for
> example (or earlier / later). Thus giving full flexibility for Kubuntu
> to align as best as you choose to the KDE release cycles.
> 
> Similarly for other Desktop Environments (XFCE, Fluxbox, MythTV etc).
> You can been as bleeding-edge or as stable as majority of your users
> expect you to.

For KDE, I can't speak for the rest, we have shipped 4.X.2 (IIRC - I didn't 
actually go back and check) for all KDE4 based releases (8.10 and later) with 
the exception of 10.10, where we shipped 4.5.1 + patches and did a ~zero day 
SRU of 4.5.2 thanks to the 10.10.10 nonsense.

In a development series we typically ship, over time, beta 1, beta 2, RC1, 
RC2, .0, .1, and (usually) .2.  There is definitely a rise in maturity through 
this progression which then drops off when we ship the first beta in the next 
release.  AIUI, part of "rolling" is to provide a stable, reliable, improving 
over time experience without significant regressions.  I don't think we can 
continue to upload the early releases in a rolling environment and accomplish 
that goal.  This is quite unfortunate, because upstream KDE branches off of 
trunk at RC1 and many developers pay start to focus on the next release then.  
Getting the KDE betas in front of a large audience is important to testing 
being done early enough to affect the end result.

This is done now through the development release and a PPA dedicated for pre-
releases on the current release so that no one gets the beta without having 
opted in in some manner.  

I'm still struggling with how to maintain the pace of testing and the quality 
reliability goals of rolling.  I haven't figured out a good solution yet.

Scott K