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

Dmitrijs Ledkovs dmitrij.ledkov at ubuntu.com
Thu Feb 28 21:29:31 UTC 2013


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.

Regards,

Dmitrijs.



More information about the ubuntu-devel mailing list