New KDE Frameworks Versions as SRU

[Rohan Garg]

On 20 Nov 2014 20:52, "Scott Kitterman" <ubuntu at kitterman.com> wrote:
>
> 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.
>

But that's additional work that we are imposing on ourselves when we could
invest that time making sure releases are  regression free.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20141120/220bcad4/attachment.html>