On Thursday, February 28, 2013 09:29:31 PM Dmitrijs Ledkovs wrote: > On 28 February 2013 20:57, Scott Kitterman <ubu...@kitterman.com> wrote: > > On Thursday, February 28, 2013 06:38:41 PM Dmitrijs Ledkovs wrote: > >> On 28 February 2013 17:16, Scott Kitterman <ubu...@kitterman.com> wrote: > >> > On Thursday, February 28, 2013 12:07:02 PM Jeremy Bicha wrote: > >> >> On 28 February 2013 16:31, Scott Kitterman <ubu...@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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel