New KDE Frameworks Versions as SRU

[Harald Sitter]

On Thu, Nov 20, 2014 at 3:44 PM, Scott Kitterman <ubuntu at kitterman.com> wrote:
> On Thursday, November 20, 2014 03:39:47 PM Harald Sitter wrote:
>> On Thu, Nov 20, 2014 at 3:34 PM, Scott Kitterman <ubuntu at kitterman.com>
> wrote:
>> > On Thursday, November 20, 2014 03:19:10 PM Jonathan Riddell wrote:
>> >> I'd like to propose to the tech board to give an update allowance for new
>> >> versions of KDE Frameworks.  I don't expect this to be the quickest of
>> >> discussions so we may as well get started :)
>> >>
>> >> Currently we have a micro release update exception for KDE SC bugfix
>> >> releases.
>> >>
>> >> KDE Frameworks has no bugfix releases because upstream decided they
>> >> didn't
>> >> have the resources to make them.  Instead they have new releases every
>> >> month with both bugfixes and new features.  However these are libraries
>> >> so
>> >> applications will be using the existing ABI and that ABI (the symbols) is
>> >> not allowed to change.  The functionality of those symbols is also not
>> >> allowed to change.  Any new features are in new symbols and existing
>> >> applications won't use them.  So updates in the archive will be bugfix
>> >> only
>> >> for applications in the archive.
>> >
>> > They already failed at this once, so I don't feel confident in this
>> > assertion.
>> So did kdelibs4.
>>
>> >> Allowing a SRU version exception will allow these bugfixes.  It will also
>> >> make it easier for backports of Plasma to use the version of KF5 in the
>> >> archive.  It will also make Kubuntu a nicer platform for people
>> >> developing
>> >> with Qt and KF5 because they'll be able to easily get the latest version.
>> >>
>> >> KF5 is in Utopic but nothing in the archive uses it so it might be a nice
>> >> way to start and reassure everyone it'll be a smooth process.
>> >>
>> >> I'd like to send this to the tech board, any thoughts?
>> >
>> > I'm against it.
>>
>> Against asking? Oo
>
> Yes.  I don't think it's appropriate to get a blanket exception given the
> upstream maintenance (or lack there of) philosophy.  So I don't think we
> should ask if we can do something I don't think we should do.

I hope the TB sees things differently then.

>> > We got the exception for KDE4 because upstream had an updates policy
>> > (which
>> > you wrote/socialized upstream) that was consistent with our SRU
>> > requirements. This is not true for KF5.  I don't think that the fact that
>> > there was an exception for KDE4 is relevant.
>>
>> Except that frameworks derive from the same code base, are made by the
>> same people and powers the continuations of previously seen kdelibs4
>> applications.
>>
>> > The upstream maintenance policy is clearly at odds with our SRU policy, so
>> > an exception is inappropriate.  Consider that it's called a micro-release
>> > exception and upstream has decided they aren't doing micro-releases at
>> > all.
>> >
>> > Since we will freeze our versions for development with a compatible KF5
>> > and
>> > Plasma 5, there's no need for newer feature versions in the archive.  We
>> > have approximately a bazillion PPAs for people that want newer crack.  We
>> > shouldn't inflict it on the entire user base.
>>
>> There is a need for bugfixes, which unfortunately may or may not
>> contain features. That being said, with frameworks being mostly
>> libraries a 'feature' is a new function, which quite simply can not
>> break existing functions by being there. C++ doesn't work like this.
>
> I completely agree bug fixes are needed.  I think it's very unfortunate that
> upstream decided to abandon their traditional post-release support.

I think the solution to that is to get yourself into a position to
influence the KDE decision making. Not blocking progress for the sake
of blocking progress.

> The
> proper fix for that, however, is not to dump the crack of the day onto all our
> users.

Crack of the day is hardly the right way to describe substantially
autotest covered software that goes through continuous integration,
static code analysis, continuous package integration, symbol tracking,
constant developer and early adopter testing, then a week or two of
PPA testing, and then a week or two of proposed testing.

HS

On Thu, Nov 20, 2014 at 3:44 PM, Scott Kitterman <ubuntu at kitterman.com> wrote:
> On Thursday, November 20, 2014 03:39:47 PM Harald Sitter wrote:
>> On Thu, Nov 20, 2014 at 3:34 PM, Scott Kitterman <ubuntu at kitterman.com>
> wrote:
>> > On Thursday, November 20, 2014 03:19:10 PM Jonathan Riddell wrote:
>> >> I'd like to propose to the tech board to give an update allowance for new
>> >> versions of KDE Frameworks.  I don't expect this to be the quickest of
>> >> discussions so we may as well get started :)
>> >>
>> >> Currently we have a micro release update exception for KDE SC bugfix
>> >> releases.
>> >>
>> >> KDE Frameworks has no bugfix releases because upstream decided they
>> >> didn't
>> >> have the resources to make them.  Instead they have new releases every
>> >> month with both bugfixes and new features.  However these are libraries
>> >> so
>> >> applications will be using the existing ABI and that ABI (the symbols) is
>> >> not allowed to change.  The functionality of those symbols is also not
>> >> allowed to change.  Any new features are in new symbols and existing
>> >> applications won't use them.  So updates in the archive will be bugfix
>> >> only
>> >> for applications in the archive.
>> >
>> > They already failed at this once, so I don't feel confident in this
>> > assertion.
>> So did kdelibs4.
>>
>> >> Allowing a SRU version exception will allow these bugfixes.  It will also
>> >> make it easier for backports of Plasma to use the version of KF5 in the
>> >> archive.  It will also make Kubuntu a nicer platform for people
>> >> developing
>> >> with Qt and KF5 because they'll be able to easily get the latest version.
>> >>
>> >> KF5 is in Utopic but nothing in the archive uses it so it might be a nice
>> >> way to start and reassure everyone it'll be a smooth process.
>> >>
>> >> I'd like to send this to the tech board, any thoughts?
>> >
>> > I'm against it.
>>
>> Against asking? Oo
>
> Yes.  I don't think it's appropriate to get a blanket exception given the
> upstream maintenance (or lack there of) philosophy.  So I don't think we
> should ask if we can do something I don't think we should do.
>
>> > We got the exception for KDE4 because upstream had an updates policy
>> > (which
>> > you wrote/socialized upstream) that was consistent with our SRU
>> > requirements. This is not true for KF5.  I don't think that the fact that
>> > there was an exception for KDE4 is relevant.
>>
>> Except that frameworks derive from the same code base, are made by the
>> same people and powers the continuations of previously seen kdelibs4
>> applications.
>>
>> > The upstream maintenance policy is clearly at odds with our SRU policy, so
>> > an exception is inappropriate.  Consider that it's called a micro-release
>> > exception and upstream has decided they aren't doing micro-releases at
>> > all.
>> >
>> > Since we will freeze our versions for development with a compatible KF5
>> > and
>> > Plasma 5, there's no need for newer feature versions in the archive.  We
>> > have approximately a bazillion PPAs for people that want newer crack.  We
>> > shouldn't inflict it on the entire user base.
>>
>> There is a need for bugfixes, which unfortunately may or may not
>> contain features. That being said, with frameworks being mostly
>> libraries a 'feature' is a new function, which quite simply can not
>> break existing functions by being there. C++ doesn't work like this.
>
> I completely agree bug fixes are needed.  I think it's very unfortunate that
> upstream decided to abandon their traditional post-release support.  The
> proper fix for that, however, is not to dump the crack of the day onto all our
> users.
>
> Scott K
>
> --
> kubuntu-devel mailing list
> kubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel