New KDE Frameworks Versions as SRU

[Harald Sitter]

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 think that was the premise really. The developers ought to spend
time moving things forward instead of backporting the odd fix (if they
remember to do so) into a branch that is going to be released with
next to no testing and adopted by possibly only 1 or 2 distros.
And that is IMO a very reasonable thing. Since no distribution picked
up on my suggestion of banding together and forming a backport target.
All sorts of meh if you ask me :/

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

Both parties are responsible I'd say. Perhaps to different degrees but
I really don't think there'd be reliability with any of the two.
And the reliability and consistency is why I am adding more QA
measures to our CI on a weekly basis.

While I don't want to expand this preliminary thread too wide I really
don't think there are many options anyway. Either we don't provide
updates in which case bugs will stay around forever (rendering the
post-release support an imaginary fairy tale) or updating with
features and do everything in our power to make sure that nothing
breaks.