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

[Scott Kitterman]

On Thursday, February 28, 2013 09:29:31 PM Dmitrijs Ledkovs wrote:
> On 28 February 2013 20:57, Scott Kitterman <ubuntu at kitterman.com> wrote:
> > 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.
> Thank you for the details. I'm looking at the past KDE release
> schedules and there appears to be a significant overlap between .4
> (sometimes .5) and the next cycle. What goes into .3+ ? I looks like
> there are updates/bugfixes to ship from previous series even at
> rc1/rc2 stages of the next release. I'm not that familiar with KDE
> releases (only used a couple of versions briefly), but it seems to me
> that those that want latest crack can use beta ppa and or nightly
> builds, while the rolling can roll between rc & point releases. I
> guess this sub-thread is more on-topic for kubuntu-devel@ mailing list
> and much depends on how the rest few weeks unfold.

The post-release updates (.1 - .4/.5) are bug fix only developed using criteria 
very similar to the Ubuntu SRU requirements, which is why we have a micro-
release exception for post release updates.  

You make my point.  The development release will no longer be a suitable 
landing place for KDE beta/RC releases, so we'll have to do that work in a PPA 
under this proposal.  This will narrow our testing base and be a complication 
when we have library transitions to deal with.

Scott K