New KDE Frameworks Versions as SRU

Rohan Garg rohangarg at kubuntu.org
Thu Nov 20 15:28:07 UTC 2014


On Thu, Nov 20, 2014 at 4:25 PM, Scott Kitterman <ubuntu at kitterman.com> wrote:
> On Thursday, November 20, 2014 04:17:07 PM Harald Sitter wrote:
>> On Thu, Nov 20, 2014 at 4:11 PM, Scott Kitterman <ubuntu at kitterman.com>
> wrote:
>> > On Thursday, November 20, 2014 03:56:13 PM Harald Sitter wrote:
>> >> >> 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.
>> >
>> > I did participate in the upstream discussion when the decision was taken.
>>
>> So clearly the arguments for bugfix releases were not good enough.
>
> My summary of the counter argument is something like "despite you packagers
> telling us the point releases are useful, we think they aren't and it would be
> less work if we didn't bother".  I wasn't the only packager in the argument,
> but I don't think they really cared.
>
>> > I don't view it as blocking progress.  I think upstream giving up on
>> > maintenance was anything but progress.  I view it as protecting our users.
>>
>> I think that should be KDE's users. We don't produce a whole lot of
>> software really.
>
> We're the integrator, so it's up to us to deliver something that's reliable
> and consistent.  That particularly includes not messing up releases.  Users
> building directly from upstream source tend to be more technical, so they can
> better stand recovering from breakage.  Keeping the release stable and
> functional is our responsibility, not theirs.
>
>> > I'm open to changing my mind in the future based on a demonstrated record
>> > of consistent success.  I don't think that exists yet.
>>
>> Fair enough.
>
> Thanks,
>
> 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


For discussion completeness :

Changelog for Frameworks 5.4.0 :
https://www.kde.org/announcements/kde-frameworks-5.4.0.php

Cheers
Rohan Garg



More information about the kubuntu-devel mailing list