Re: New KDE Frameworks Versions as SRU
On Thursday, November 20, 2014 09:04:52 PM Rohan Garg wrote: Major snippage for readability > > > 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. Compared to what? Are you suggesting that we also be allowed to push minor version updates through -security to resolve security issues? That's far more unusual than micro-release updates via SRU. We're going to have to address security issues distinctly anyway, regardless of what's done with minor version updates. For the non-security releases, if there are so many severe bugs that packaging up the fixes is a lot of work, then I seriously question if the software is of high enough quality to merit an exception. This isn't, IMO, really about how much work it takes to provide fixes for severe/security bugs. Its about providing minor fixes and new features. Scott K -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New KDE Frameworks Versions as SRU
On 20 Nov 2014 20:52, "Scott Kitterman" wrote: > > On Thursday, November 20, 2014 05:36:42 PM Harald Sitter wrote: > > On Thu, Nov 20, 2014 at 4:25 PM, Scott Kitterman > wrote: > > > On Thursday, November 20, 2014 04:17:07 PM Harald Sitter wrote: > > >> On Thu, Nov 20, 2014 at 4:11 PM, Scott Kitterman < ubu...@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. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New KDE Frameworks Versions as SRU
On Thursday, November 20, 2014 05:36:42 PM Harald Sitter wrote: > On Thu, Nov 20, 2014 at 4:25 PM, Scott Kitterman wrote: > > On Thursday, November 20, 2014 04:17:07 PM Harald Sitter wrote: > >> On Thu, Nov 20, 2014 at 4:11 PM, Scott Kitterman > > > > 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 kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New KDE Frameworks Versions as SRU
On Thu, Nov 20, 2014 at 4:25 PM, Scott Kitterman wrote: > On Thursday, November 20, 2014 04:17:07 PM Harald Sitter wrote: >> On Thu, Nov 20, 2014 at 4:11 PM, Scott Kitterman > 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 kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New KDE Frameworks Versions as SRU
On 2014-11-20 10:25, Scott Kitterman wrote: On Thursday, November 20, 2014 04:17:07 PM Harald Sitter wrote: On Thu, Nov 20, 2014 at 4:11 PM, Scott Kitterman 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 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. I understand your point and don't 100% disagree with it. However, there is somewhat a paradox. When there is a bugfix that is not applied, the code has already a breakage. So the stability of the release in this moment also contains the stable existence of breakages. The real question is if the old or the new release has qualitatively the better quality, which is often not easy to decide, but leads to the dilemma that for important software, I as a professional cannot rely on integrators anymore. I know that is not the same scope, but look at drupal. Does Ubuntu already have the security fixes from the last 4 weeks integrated? There is a serious sql injection problem in the code that is currently in the Ubuntu archives. This is a problem for all users not only for technical ones (https://www.drupal.org/SA-CORE-2014-005). So I see the version 7.26 in the Ubuntu LTS, but it should be at least 7.32, or better 7.34. I am aware that there is a difference between KDE and Drupal, and as I said before, I don't disagree with your notion. Obviously, regressions should be avoided. However, there is a fundamental problem that is not just leaning on one side or the other. > I'm open to changing my mind in the future based on a demonstrated record > of consistent success. I don't think that exists yet. Fair enough. Thanks, Scott K -- txwikinger Long live free/libre software -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New KDE Frameworks Versions as SRU
On Thu, Nov 20, 2014 at 09:34:43AM -0500, Scott Kitterman wrote: > > KDE Frameworks has no bugfix releases because upstream decided they didn't > > have the resources to make them. Instead they have new releases every > > month with both bugfixes and new features. However these are libraries so > > applications will be using the existing ABI and that ABI (the symbols) is > > not allowed to change. The functionality of those symbols is also not > > allowed to change. Any new features are in new symbols and existing > > applications won't use them. So updates in the archive will be bugfix only > > for applications in the archive. > > They already failed at this once, so I don't feel confident in this assertion. They introduced a regression but that wasn't while adding a new feature it was while adding a bugfix. This also happened with kdelibs. > We got the exception for KDE4 because upstream had an updates policy (which > you wrote/socialized upstream) that was consistent with our SRU requirements. > > This is not true for KF5. I don't think that the fact that there was an > exception for KDE4 is relevant. > > The upstream maintenance policy is clearly at odds with our SRU policy, so an > exception is inappropriate. Consider that it's called a micro-release > exception and upstream has decided they aren't doing micro-releases at all. The KDE Minor Point Release Policy isn't used for KDE Frameworks indeed but they are libraries, they don't change the ABI or the features they expose so the only relevant parts of the update are bugfixes. It should be quite possible to get it in an Ubuntu SRU. I'd like to ask the tech board at the least. Jonathan -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New KDE Frameworks Versions as SRU
On Thu, Nov 20, 2014 at 4:25 PM, Scott Kitterman wrote: > On Thursday, November 20, 2014 04:17:07 PM Harald Sitter wrote: >> On Thu, Nov 20, 2014 at 4:11 PM, Scott Kitterman > 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 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. > >> > I'm open to changing my mind in the future based on a demonstrated record >> > of consistent success. I don't think that exists yet. >> >> Fair enough. > > Thanks, > > Scott K > > -- > kubuntu-devel mailing list > kubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel For discussion completeness : Changelog for Frameworks 5.4.0 : https://www.kde.org/announcements/kde-frameworks-5.4.0.php Cheers Rohan Garg -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New KDE Frameworks Versions as SRU
On Thursday, November 20, 2014 04:17:07 PM Harald Sitter wrote: > On Thu, Nov 20, 2014 at 4:11 PM, Scott Kitterman 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 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. > > I'm open to changing my mind in the future based on a demonstrated record > > of consistent success. I don't think that exists yet. > > Fair enough. Thanks, Scott K -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New KDE Frameworks Versions as SRU
On Thu, Nov 20, 2014 at 4:11 PM, Scott Kitterman 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. > 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. > I'm open to changing my mind in the future based on a demonstrated record of > consistent success. I don't think that exists yet. Fair enough. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New KDE Frameworks Versions as SRU
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. 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'm open to changing my mind in the future based on a demonstrated record of consistent success. I don't think that exists yet. Scott K -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New KDE Frameworks Versions as SRU
> Crack of the day is hardly the right way to describe substantially > autotest covered software that goes through continuous integration, > static code analysis, continuous package integration, symbol tracking, > constant developer and early adopter testing, then a week or two of > PPA testing, and then a week or two of proposed testing. > Seconded, our CI system has extensive QA measures and should be more than enough to satisfy SRU QA requirements even though KDE Frameworks might not fit with the Ubuntu SRU policy. If we do find issues, we should move towards extending QA measures on the CI instead of blocking updates for end users. Cheers Rohan Garg -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New KDE Frameworks Versions as SRU
On Thu, Nov 20, 2014 at 3:44 PM, Scott Kitterman wrote: > On Thursday, November 20, 2014 03:39:47 PM Harald Sitter wrote: >> On Thu, Nov 20, 2014 at 3:34 PM, Scott Kitterman > wrote: >> > On Thursday, November 20, 2014 03:19:10 PM Jonathan Riddell wrote: >> >> I'd like to propose to the tech board to give an update allowance for new >> >> versions of KDE Frameworks. I don't expect this to be the quickest of >> >> discussions so we may as well get started :) >> >> >> >> Currently we have a micro release update exception for KDE SC bugfix >> >> releases. >> >> >> >> KDE Frameworks has no bugfix releases because upstream decided they >> >> didn't >> >> have the resources to make them. Instead they have new releases every >> >> month with both bugfixes and new features. However these are libraries >> >> so >> >> applications will be using the existing ABI and that ABI (the symbols) is >> >> not allowed to change. The functionality of those symbols is also not >> >> allowed to change. Any new features are in new symbols and existing >> >> applications won't use them. So updates in the archive will be bugfix >> >> only >> >> for applications in the archive. >> > >> > They already failed at this once, so I don't feel confident in this >> > assertion. >> So did kdelibs4. >> >> >> Allowing a SRU version exception will allow these bugfixes. It will also >> >> make it easier for backports of Plasma to use the version of KF5 in the >> >> archive. It will also make Kubuntu a nicer platform for people >> >> developing >> >> with Qt and KF5 because they'll be able to easily get the latest version. >> >> >> >> KF5 is in Utopic but nothing in the archive uses it so it might be a nice >> >> way to start and reassure everyone it'll be a smooth process. >> >> >> >> I'd like to send this to the tech board, any thoughts? >> > >> > I'm against it. >> >> Against asking? Oo > > Yes. I don't think it's appropriate to get a blanket exception given the > upstream maintenance (or lack there of) philosophy. So I don't think we > should ask if we can do something I don't think we should do. I hope the TB sees things differently then. >> > We got the exception for KDE4 because upstream had an updates policy >> > (which >> > you wrote/socialized upstream) that was consistent with our SRU >> > requirements. This is not true for KF5. I don't think that the fact that >> > there was an exception for KDE4 is relevant. >> >> Except that frameworks derive from the same code base, are made by the >> same people and powers the continuations of previously seen kdelibs4 >> applications. >> >> > The upstream maintenance policy is clearly at odds with our SRU policy, so >> > an exception is inappropriate. Consider that it's called a micro-release >> > exception and upstream has decided they aren't doing micro-releases at >> > all. >> > >> > Since we will freeze our versions for development with a compatible KF5 >> > and >> > Plasma 5, there's no need for newer feature versions in the archive. We >> > have approximately a bazillion PPAs for people that want newer crack. We >> > shouldn't inflict it on the entire user base. >> >> 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. > The > proper fix for that, however, is not to dump the crack of the day onto all our > users. Crack of the day is hardly the right way to describe substantially autotest covered software that goes through continuous integration, static code analysis, continuous package integration, symbol tracking, constant developer and early adopter testing, then a week or two of PPA testing, and then a week or two of proposed testing. HS On Thu, Nov 20, 2014 at 3:44 PM, Scott Kitterman wrote: > On Thursday, November 20, 2014 03:39:47 PM Harald Sitter wrote: >> On Thu, Nov 20, 2014 at 3:34 PM, Scott Kitterman > wrote: >> > On Thursday, November 20, 2014 03:19:10 PM Jonathan Riddell wrote: >> >> I'd like to propose to the tech board to give an update allowance for new >> >> versions of KDE Frameworks. I don't expect this to be the quickest of >> >> discussions so we may as well get started :) >> >> >> >> Currently we have a micro release update exception for KDE SC bugfix >> >> releases. >> >> >> >> KDE Frameworks has no bugfix releases because upstream decided they >> >> didn't >> >> have the resources to make them. Instead they have new releases every >> >> month with both bugfixes and new features. However these are libraries >> >> so >>
Re: New KDE Frameworks Versions as SRU
On Thursday, November 20, 2014 03:39:47 PM Harald Sitter wrote: > On Thu, Nov 20, 2014 at 3:34 PM, Scott Kitterman wrote: > > On Thursday, November 20, 2014 03:19:10 PM Jonathan Riddell wrote: > >> I'd like to propose to the tech board to give an update allowance for new > >> versions of KDE Frameworks. I don't expect this to be the quickest of > >> discussions so we may as well get started :) > >> > >> Currently we have a micro release update exception for KDE SC bugfix > >> releases. > >> > >> KDE Frameworks has no bugfix releases because upstream decided they > >> didn't > >> have the resources to make them. Instead they have new releases every > >> month with both bugfixes and new features. However these are libraries > >> so > >> applications will be using the existing ABI and that ABI (the symbols) is > >> not allowed to change. The functionality of those symbols is also not > >> allowed to change. Any new features are in new symbols and existing > >> applications won't use them. So updates in the archive will be bugfix > >> only > >> for applications in the archive. > > > > They already failed at this once, so I don't feel confident in this > > assertion. > So did kdelibs4. > > >> Allowing a SRU version exception will allow these bugfixes. It will also > >> make it easier for backports of Plasma to use the version of KF5 in the > >> archive. It will also make Kubuntu a nicer platform for people > >> developing > >> with Qt and KF5 because they'll be able to easily get the latest version. > >> > >> KF5 is in Utopic but nothing in the archive uses it so it might be a nice > >> way to start and reassure everyone it'll be a smooth process. > >> > >> I'd like to send this to the tech board, any thoughts? > > > > I'm against it. > > Against asking? Oo Yes. I don't think it's appropriate to get a blanket exception given the upstream maintenance (or lack there of) philosophy. So I don't think we should ask if we can do something I don't think we should do. > > We got the exception for KDE4 because upstream had an updates policy > > (which > > you wrote/socialized upstream) that was consistent with our SRU > > requirements. This is not true for KF5. I don't think that the fact that > > there was an exception for KDE4 is relevant. > > Except that frameworks derive from the same code base, are made by the > same people and powers the continuations of previously seen kdelibs4 > applications. > > > The upstream maintenance policy is clearly at odds with our SRU policy, so > > an exception is inappropriate. Consider that it's called a micro-release > > exception and upstream has decided they aren't doing micro-releases at > > all. > > > > Since we will freeze our versions for development with a compatible KF5 > > and > > Plasma 5, there's no need for newer feature versions in the archive. We > > have approximately a bazillion PPAs for people that want newer crack. We > > shouldn't inflict it on the entire user base. > > 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. The proper fix for that, however, is not to dump the crack of the day onto all our users. Scott K -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New KDE Frameworks Versions as SRU
On Thu, Nov 20, 2014 at 3:34 PM, Scott Kitterman wrote: > On Thursday, November 20, 2014 03:19:10 PM Jonathan Riddell wrote: >> I'd like to propose to the tech board to give an update allowance for new >> versions of KDE Frameworks. I don't expect this to be the quickest of >> discussions so we may as well get started :) >> >> Currently we have a micro release update exception for KDE SC bugfix >> releases. >> >> KDE Frameworks has no bugfix releases because upstream decided they didn't >> have the resources to make them. Instead they have new releases every >> month with both bugfixes and new features. However these are libraries so >> applications will be using the existing ABI and that ABI (the symbols) is >> not allowed to change. The functionality of those symbols is also not >> allowed to change. Any new features are in new symbols and existing >> applications won't use them. So updates in the archive will be bugfix only >> for applications in the archive. > > They already failed at this once, so I don't feel confident in this assertion. So did kdelibs4. >> Allowing a SRU version exception will allow these bugfixes. It will also >> make it easier for backports of Plasma to use the version of KF5 in the >> archive. It will also make Kubuntu a nicer platform for people developing >> with Qt and KF5 because they'll be able to easily get the latest version. >> >> KF5 is in Utopic but nothing in the archive uses it so it might be a nice >> way to start and reassure everyone it'll be a smooth process. >> >> I'd like to send this to the tech board, any thoughts? > > I'm against it. Against asking? Oo > We got the exception for KDE4 because upstream had an updates policy (which > you wrote/socialized upstream) that was consistent with our SRU requirements. > This is not true for KF5. I don't think that the fact that there was an > exception for KDE4 is relevant. Except that frameworks derive from the same code base, are made by the same people and powers the continuations of previously seen kdelibs4 applications. > The upstream maintenance policy is clearly at odds with our SRU policy, so an > exception is inappropriate. Consider that it's called a micro-release > exception and upstream has decided they aren't doing micro-releases at all. > > Since we will freeze our versions for development with a compatible KF5 and > Plasma 5, there's no need for newer feature versions in the archive. We have > approximately a bazillion PPAs for people that want newer crack. We shouldn't > inflict it on the entire user base. 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. HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New KDE Frameworks Versions as SRU
On Thursday, November 20, 2014 03:19:10 PM Jonathan Riddell wrote: > I'd like to propose to the tech board to give an update allowance for new > versions of KDE Frameworks. I don't expect this to be the quickest of > discussions so we may as well get started :) > > Currently we have a micro release update exception for KDE SC bugfix > releases. > > KDE Frameworks has no bugfix releases because upstream decided they didn't > have the resources to make them. Instead they have new releases every > month with both bugfixes and new features. However these are libraries so > applications will be using the existing ABI and that ABI (the symbols) is > not allowed to change. The functionality of those symbols is also not > allowed to change. Any new features are in new symbols and existing > applications won't use them. So updates in the archive will be bugfix only > for applications in the archive. They already failed at this once, so I don't feel confident in this assertion. > Allowing a SRU version exception will allow these bugfixes. It will also > make it easier for backports of Plasma to use the version of KF5 in the > archive. It will also make Kubuntu a nicer platform for people developing > with Qt and KF5 because they'll be able to easily get the latest version. > > KF5 is in Utopic but nothing in the archive uses it so it might be a nice > way to start and reassure everyone it'll be a smooth process. > > I'd like to send this to the tech board, any thoughts? I'm against it. We got the exception for KDE4 because upstream had an updates policy (which you wrote/socialized upstream) that was consistent with our SRU requirements. This is not true for KF5. I don't think that the fact that there was an exception for KDE4 is relevant. The upstream maintenance policy is clearly at odds with our SRU policy, so an exception is inappropriate. Consider that it's called a micro-release exception and upstream has decided they aren't doing micro-releases at all. Since we will freeze our versions for development with a compatible KF5 and Plasma 5, there's no need for newer feature versions in the archive. We have approximately a bazillion PPAs for people that want newer crack. We shouldn't inflict it on the entire user base. Scott K -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
