On 20 Nov 2014 20:52, "Scott Kitterman" <<a href="mailto:ubuntu@kitterman.com">ubuntu@kitterman.com</a>> wrote: > > On Thursday, November 20, 2014 05:36:42 PM Harald Sitter wrote: > > On Thu, Nov 20, 2014 at 4:25 PM, Scott Kitterman <<a href="mailto:ubuntu@kitterman.com">ubuntu@kitterman.com</a>> > wrote: > > > On Thursday, November 20, 2014 04:17:07 PM Harald Sitter wrote: > > >> On Thu, Nov 20, 2014 at 4:11 PM, Scott Kitterman <<a href="mailto:ubuntu@kitterman.com">ubuntu@kitterman.com</a>> > > > > > > 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.