Kubuntu 15.04

[Scott Kitterman]

On Thursday, October 30, 2014 22:18:02 Harald Sitter wrote:
> On Thu, Oct 30, 2014 at 10:12 PM, Scott Kitterman <ubuntu at kitterman.com> 
wrote:
> > On Thursday, October 30, 2014 22:08:02 Harald Sitter wrote:
> >> On Thu, Oct 30, 2014 at 9:10 PM, Scott Kitterman <ubuntu at kitterman.com>
> > 
> > wrote:
> >> > On Thursday, October 30, 2014 12:19:58 Harald Sitter wrote:
> >> >> On Wed, Oct 29, 2014 at 12:40 PM, Jonathan Riddell <jr at jriddell.org>
> > 
> > wrote:
> >> >> > On Wed, Oct 29, 2014 at 12:37:16AM +0000, Rick.Timmis wrote:
> >> >> >>    The Plasma 5 release dude is all for it and the Plasma 5 dude
> >> >> >>    who's
> >> >> >>    sitting next to him is also all for it.  Nobody upstream has
> >> >> >>    said
> >> >> >>    anything against it they're just disappointed that we'd be
> >> >> >>    shipping
> >> >> >>    Plasma 5.2 and not 5.3 (out the week after Kubuntu 15.04).
> >> >> > 
> >> >> > Nobody seems to object, so I'm going to say we'll have Plasma 5 by
> >> >> > default
> >> >> > in Kubuntu 15.04.
> >> >> 
> >> >> Needs papers to be filed with TB to seek blanket SRU approval for KF5.
> >> >> Otherwise we need to work out a way to get newer frameworks into our
> >> >> released versions as to enable people to get bug fixes.
> >> > 
> >> > No.  We don't.
> >> > 
> >> > KF5 doesn't meet the criteria for a standing SRU exception and since
> >> > the
> >> > last KF5 update broke Plasma 5, I think we've got no basis for claiming
> >> > upstream feature releases are sufficiently low risk that non-bugfix
> >> > releases are acceptable for post-release updates.
> >> 
> >> That was intentionally done because no distribution had adopted p5 as
> >> primary desktop in a release. At any rate I think a proposal should be
> >> made and then we can engage upstream on actual TB concerns and see
> >> where we get from there.
> >> 
> >> > This should be no surprise.  This was all discussed when upstream
> >> > decided
> >> > not to provide support for current releases.  We'll have to cherrypick
> >> > and do our best with imprant bug fixes via the normal SRU process.
> >> 
> >> Since backporting is not going to happen but for the most obnoxiously
> >> terrible bugs that are being highlighted on IRC, perhaps it would be
> >> an opportune moment to evaluate the release procedure as a whole.
> >> Assuming we do not get to an agreement on a standing SRU exception
> >> we'd be pretty much delivering fixes through PPA releases only. It
> >> might be worth a consideration or two to simply transit to an entirely
> >> PPA based release delivery system as that is what people will have to
> >> use if they want fixes anyway. And that being said, another option
> >> would be to stop having non-LTS releases and instead do a PPA delivery
> >> against the latest LTS release (which due to the foundation
> >> backporting efforts might actually work pretty well for the most part)
> >> leaving more focused efforts to be directed at LTS maintenance and
> >> rolling the PPA forward.
> >> 
> >> My point being: selective backporting didn't fly in the past and isn't
> >> going to magically become easier or more appealing which makes this an
> >> undesirable scenario to end up with. In particular when there's plenty
> >> of options.
> > 
> > While a PPA based system is sort of OK for a tech preview like was done in
> > 14.10, it's not viable for an Ubuntu flavor.
> 
> Well, it wouldn't be the same workflow as in the TP. The way I would
> imagine it is simply having a release PPA where usually the archive
> would be in our workflows. Alas, I don't like PPA-only delivery as
> that would make it all the harder for archive software to use kf5 and
> for us to make sure that kf5 (in a ppa) doesn't break something in the
> archive. It is an option though.

AIUI, it's not if we're going to remain an official flavor in the Ubuntu project.  
We can argue about it in detail when we get to it though.

Scott K