On Thu, Nov 20, 2014 at 4:25 PM, Scott Kitterman <[email protected]> wrote: > On Thursday, November 20, 2014 04:17:07 PM Harald Sitter wrote: >> On Thu, Nov 20, 2014 at 4:11 PM, Scott Kitterman <[email protected]> > 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. -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
