New KDE Frameworks Versions as SRU

Ralph Janke txwikinger at ubuntu.com
Thu Nov 20 16:28:47 UTC 2014


On 2014-11-20 10:25, Scott Kitterman 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 understand your point and don't 100% disagree with it. However, there 
is
somewhat a paradox. When there is a bugfix that is not applied, the code
has already a breakage. So the stability of the release in this moment 
also
contains the stable existence of breakages.

The real question is if the old or the new release has qualitatively the 
better
quality, which is often not easy to decide, but leads to the dilemma 
that
for important software, I as a professional cannot rely on integrators 
anymore.
I know that is not the same scope, but look at drupal. Does Ubuntu 
already have
the security fixes from the last 4 weeks integrated? There is a serious 
sql injection
problem in the code that is currently in the Ubuntu archives. This is a 
problem
for all users not only for technical ones 
(https://www.drupal.org/SA-CORE-2014-005).
So I see the version 7.26 in the Ubuntu LTS, but it should be at least 
7.32, or
better 7.34.

I am aware that there is a difference between KDE and Drupal, and as I 
said before,
I don't disagree with your notion. Obviously, regressions should be 
avoided. However,
there is a fundamental problem that is not just leaning on one side or 
the other.

>> > 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

-- 
txwikinger

Long live free/libre software



More information about the kubuntu-devel mailing list