On Thursday, November 20, 2014 05:36:42 PM Harald Sitter wrote: > 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.
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 -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
