New KDE Frameworks Versions as SRU

[Scott Kitterman]

On Thursday, November 20, 2014 05:36:42 PM Harald Sitter wrote:
> 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.

If we limit our post-release updates to security fixes and very serious bugs, I 
think that's fine.  That's what support is.

Scott K