Re: Plasma 5 on nvidia
Mitch Golden wrote:I am posting this here because I don't know exactly where it should be posted. I have installed 14.10 Plasma 5 on my laptop, which is a vintage 2011 System 76. Of greatest significance is that it has an nvidia 560M graphics card in it. When I first installed 14.04, I noticed that the PowerMizer report of the NVIDIA X Server Settings would report that the graphics chip's clock was more or less constantly spun up to its highest clock rate. Heat and power use were very high, and I constantly heard the fan running. I found there were two ways to fix this: (1) Add a file called 05-nvidia.conf to /usr/share/X11/xorg.conf.d containing the lines: Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" Option "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x; PowerMizerDefault=0x3; PowerMizerDefaultAC=0x3" EndSection This pegged the graphics card at its lowest possible clock rate, which was adequate for most things but sometimes led to bad playback on some videos. See: https://forums.opensuse.org/showthread.php/410089-nvidia-powermizer-how-tweak (2) Revert to the 304 driver. This still spun up to high clock rates a bit more often than it seemed to need to, but was fairly reasonable otherwise. I expected that this would soon be rectified, since I saw that version 337.25 of the driver allegedly fixed some issue with performance in KDE: http://www.nvidia.com/download/driverResults.aspx/76278/en-us Jump ahead to yesterday when I installed 14.10 plasma 5 - I noticed that even with the 304 driver the PowerMizer reported the clock at its highest rate. With nothing moving on the screen at all and my not touching the mouse, it was pegged. I found that even installing the xorg-edgers driver (340 I believe) had no effect. Furthermore, 340 did not respond to the xorg.conf settings file above. The only way I can get plasma 5 to run reasonably on this machine is to revert to 304 and *also* put the settings file in. This is of course not optimal. Perhaps the installer can be made to configure this stuff properly for nvidia machines, or at least instructions can be added. I have additional bugs/comments to make on the behavior of plasma 5. I don't see any instructions on the download place as to where they should go. Pointers kindly appreciated. - Mitch Golden -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel Hi Mitch Thank you for this excellently written Bug report. I have opened a Bug on launchpad.net for this issue, with my initial thoughts being that the Ubiquity installer team will want to know about this. https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1394856 I shall look to triage in due course, as I have a Samsung with an Nvidia GPU For other bugs and issues, you can also report them to bugs.launchpad.net and I would encourage you to open a launchpad account. This will enable you to comment and add detail to the above Bug too. Finally you can also get hold of us on IRC in #kubuntu or #kubuntu-devel HTH Rick Timmis-- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Plasma 5 on nvidia
I am posting this here because I don't know exactly where it should be posted. I have installed 14.10 Plasma 5 on my laptop, which is a vintage 2011 System 76. Of greatest significance is that it has an nvidia 560M graphics card in it. When I first installed 14.04, I noticed that the PowerMizer report of the NVIDIA X Server Settings would report that the graphics chip's clock was more or less constantly spun up to its highest clock rate. Heat and power use were very high, and I constantly heard the fan running. I found there were two ways to fix this: (1) Add a file called 05-nvidia.conf to /usr/share/X11/xorg.conf.d containing the lines: Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" Option "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x; PowerMizerDefault=0x3; PowerMizerDefaultAC=0x3" EndSection This pegged the graphics card at its lowest possible clock rate, which was adequate for most things but sometimes led to bad playback on some videos. See: https://forums.opensuse.org/showthread.php/410089-nvidia-powermizer-how-tweak (2) Revert to the 304 driver. This still spun up to high clock rates a bit more often than it seemed to need to, but was fairly reasonable otherwise. I expected that this would soon be rectified, since I saw that version 337.25 of the driver allegedly fixed some issue with performance in KDE: http://www.nvidia.com/download/driverResults.aspx/76278/en-us Jump ahead to yesterday when I installed 14.10 plasma 5 - I noticed that even with the 304 driver the PowerMizer reported the clock at its highest rate. With nothing moving on the screen at all and my not touching the mouse, it was pegged. I found that even installing the xorg-edgers driver (340 I believe) had no effect. Furthermore, 340 did not respond to the xorg.conf settings file above. The only way I can get plasma 5 to run reasonably on this machine is to revert to 304 and *also* put the settings file in. This is of course not optimal. Perhaps the installer can be made to configure this stuff properly for nvidia machines, or at least instructions can be added. I have additional bugs/comments to make on the behavior of plasma 5. I don't see any instructions on the download place as to where they should go. Pointers kindly appreciated. - Mitch Golden -- 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 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: [Merge] lp:~bzoltan/kubuntu-packaging/proper_naming into lp:~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src
Review: Needs Fixing
Thanks. Some more comments on the fixes though:
- you removed also ", ${misc:Depends}", please add that back to the
transitional packages deps
- the version deps should be in ():s in Breaks/Replaces
--
https://code.launchpad.net/~bzoltan/kubuntu-packaging/proper_naming/+merge/242179
Your team Kubuntu Packagers is subscribed to branch
lp:~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src.
--
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: Ktorrent Status/Replacement
On Thursday, November 20, 2014 11:04:54 AM Ralph Janke wrote: > On 2014-11-20 10:26, Scarlett Clark wrote: > > On Thursday, November 20, 2014 10:21:41 AM Ralph Janke wrote: > >> On 2014-11-20 09:34, Harald Sitter wrote: > >> > On Thu, Nov 20, 2014 at 3:27 PM, Scott Kitterman > >> > > >> > wrote: > >> >> On Thursday, November 20, 2014 03:17:33 PM Harald Sitter wrote: > >> >>> fwiw if only we had a policy to deal with dead upstreams > >> >>> > >> >>> On Mon, Nov 17, 2014 at 2:37 PM, Scott Kitterman > >> >>> > >> >> > >> >> wrote: > >> >>> > Ktorrent is the current default torrent client that we provide in > >> >>> > Kubuntu. > >> >>> > Now that we've transitioned to Plasma 5, it's no longer > >> >>> > buildable/installable in "Vivid". > >> >>> > > >> >>> > The upstream web site is down: http://ktorrent.org/ > >> >>> > >> >>> ^ that wouldn't be the qualifier on whether it suffers from dead > >> >>> upstream > >> >>> > >> >>> > I looked in KDE git and there's no sign of a KF5/Plasma 5 port: > >> >>> > https://projects.kde.org/projects/extragear/network/ktorrent/reposi > >> >>> > tor > >> >>> > y > >> >>> > >> >>> ^ that wouldn't either > >> >>> > >> >>> > My conclusion is that ktorrent isn't an option for Vivid, so we > >> >>> > either > >> >>> > need to stop shipping a torrent client or pick a different one. > >> >>> > >> >>> ^ those wouldn't be the primary options > >> >>> > >> >>> food for thought > >> >> > >> >> JR fixed it, so it's not an immediate issue. > >> >> > >> >> IMO it wasn't so much a dead upstream issue as a no longer works with > >> >> Plasma 5 > >> >> issue. The dead upstream just made that less likely to get better on > >> >> its own. > >> > > >> > my point is that there is no dead upstream, as no one tried to talk to > >> > upstream (nor brought it to the attention of the large kde developer > >> > community). > >> > >> The question is IMHO if you could ever consider an upstream dead. By > >> definition > >> this would mean that it would never become alive again. However, in > >> Open > >> Source, > >> anybody can pick up the source and so a new group of people can take > >> over the > >> maintenance without anybody else being able to prevent it. > >> > >> So I would rephrase this question. How would you consider that a > >> source > >> is > >> obsolete in the sense that there is a better one the replaces the > >> first > >> one > >> and it does not make sense to put any kind of work in it anymore. Or, > >> if > >> it > >> is still a valid choice, how to create the helpful flow of information > >> that > >> allows people to step forward to keep it maintained. > > > > Just an FYI Ktorrent is next on the Gardening team to do. We were able > > to get > > a new release with k3b and sparked new life into it. Please don't deem > > Ktorrent dead just yet. > > Scarlett > > So, How would I be able to contribute to the gardening of ktorrent > without > spending a lot of time with administrative stuff? While I am passionate > about > writing software, I have grown tired with the administrative hurdles in > Open Source projects and currently rather started my own projects which > I > can just work on whenever I like to. However, I am willing to give it > another > try with ktorrent (or other similar things) if it helps. Gardening is a great project, no commitments required. All help is welcome. You can find more info here: https://community.kde.org/Gardening Thanks, Scarlett -- Scarlett Clark Kubuntu Developer KDE Contributor IRC: sgclark Email: sgcl...@kubuntu.org signature.asc Description: This is a digitally signed message part. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Ktorrent Status/Replacement
On 2014-11-20 10:26, Scarlett Clark wrote: On Thursday, November 20, 2014 10:21:41 AM Ralph Janke wrote: On 2014-11-20 09:34, Harald Sitter wrote: > On Thu, Nov 20, 2014 at 3:27 PM, Scott Kitterman > > wrote: >> On Thursday, November 20, 2014 03:17:33 PM Harald Sitter wrote: >>> fwiw if only we had a policy to deal with dead upstreams >>> >>> On Mon, Nov 17, 2014 at 2:37 PM, Scott Kitterman >>> >> >> wrote: >>> > Ktorrent is the current default torrent client that we provide in >>> > Kubuntu. >>> > Now that we've transitioned to Plasma 5, it's no longer >>> > buildable/installable in "Vivid". >>> > >>> > The upstream web site is down: http://ktorrent.org/ >>> >>> ^ that wouldn't be the qualifier on whether it suffers from dead >>> upstream >>> >>> > I looked in KDE git and there's no sign of a KF5/Plasma 5 port: >>> > https://projects.kde.org/projects/extragear/network/ktorrent/repositor >>> > y >>> >>> ^ that wouldn't either >>> >>> > My conclusion is that ktorrent isn't an option for Vivid, so we either >>> > need to stop shipping a torrent client or pick a different one. >>> >>> ^ those wouldn't be the primary options >>> >>> food for thought >> >> JR fixed it, so it's not an immediate issue. >> >> IMO it wasn't so much a dead upstream issue as a no longer works with >> Plasma 5 >> issue. The dead upstream just made that less likely to get better on >> its own. > > my point is that there is no dead upstream, as no one tried to talk to > upstream (nor brought it to the attention of the large kde developer > community). The question is IMHO if you could ever consider an upstream dead. By definition this would mean that it would never become alive again. However, in Open Source, anybody can pick up the source and so a new group of people can take over the maintenance without anybody else being able to prevent it. So I would rephrase this question. How would you consider that a source is obsolete in the sense that there is a better one the replaces the first one and it does not make sense to put any kind of work in it anymore. Or, if it is still a valid choice, how to create the helpful flow of information that allows people to step forward to keep it maintained. Just an FYI Ktorrent is next on the Gardening team to do. We were able to get a new release with k3b and sparked new life into it. Please don't deem Ktorrent dead just yet. Scarlett So, How would I be able to contribute to the gardening of ktorrent without spending a lot of time with administrative stuff? While I am passionate about writing software, I have grown tired with the administrative hurdles in Open Source projects and currently rather started my own projects which I can just work on whenever I like to. However, I am willing to give it another try with ktorrent (or other similar things) if it helps. -- 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: Ktorrent Status/Replacement
On Thu, Nov 20, 2014 at 4:26 PM, Scarlett Clark wrote: > On Thursday, November 20, 2014 10:21:41 AM Ralph Janke wrote: >> On 2014-11-20 09:34, Harald Sitter wrote: >> > On Thu, Nov 20, 2014 at 3:27 PM, Scott Kitterman >> > >> > wrote: >> >> On Thursday, November 20, 2014 03:17:33 PM Harald Sitter wrote: >> >>> fwiw if only we had a policy to deal with dead upstreams >> >>> >> >>> On Mon, Nov 17, 2014 at 2:37 PM, Scott Kitterman >> >>> >> >> >> >> wrote: >> >>> > Ktorrent is the current default torrent client that we provide in >> >>> > Kubuntu. >> >>> > Now that we've transitioned to Plasma 5, it's no longer >> >>> > buildable/installable in "Vivid". >> >>> > >> >>> > The upstream web site is down: http://ktorrent.org/ >> >>> >> >>> ^ that wouldn't be the qualifier on whether it suffers from dead >> >>> upstream >> >>> >> >>> > I looked in KDE git and there's no sign of a KF5/Plasma 5 port: >> >>> > https://projects.kde.org/projects/extragear/network/ktorrent/repositor >> >>> > y >> >>> >> >>> ^ that wouldn't either >> >>> >> >>> > My conclusion is that ktorrent isn't an option for Vivid, so we either >> >>> > need to stop shipping a torrent client or pick a different one. >> >>> >> >>> ^ those wouldn't be the primary options >> >>> >> >>> food for thought >> >> >> >> JR fixed it, so it's not an immediate issue. >> >> >> >> IMO it wasn't so much a dead upstream issue as a no longer works with >> >> Plasma 5 >> >> issue. The dead upstream just made that less likely to get better on >> >> its own. >> > >> > my point is that there is no dead upstream, as no one tried to talk to >> > upstream (nor brought it to the attention of the large kde developer >> > community). > >> >> The question is IMHO if you could ever consider an upstream dead. By >> definition >> this would mean that it would never become alive again. However, in Open >> Source, >> anybody can pick up the source and so a new group of people can take >> over the >> maintenance without anybody else being able to prevent it. >> >> So I would rephrase this question. How would you consider that a source >> is >> obsolete in the sense that there is a better one the replaces the first >> one >> and it does not make sense to put any kind of work in it anymore. Or, if >> it >> is still a valid choice, how to create the helpful flow of information >> that >> allows people to step forward to keep it maintained. > > Just an FYI Ktorrent is next on the Gardening team to do. We were able to get > a new release with k3b and sparked new life into it. Please don't deem > Ktorrent dead just yet. > Scarlett q.e.d. -- 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: Ktorrent Status/Replacement
On Thursday, November 20, 2014 10:21:41 AM Ralph Janke wrote: > On 2014-11-20 09:34, Harald Sitter wrote: > > On Thu, Nov 20, 2014 at 3:27 PM, Scott Kitterman > > > > wrote: > >> On Thursday, November 20, 2014 03:17:33 PM Harald Sitter wrote: > >>> fwiw if only we had a policy to deal with dead upstreams > >>> > >>> On Mon, Nov 17, 2014 at 2:37 PM, Scott Kitterman > >>> > >> > >> wrote: > >>> > Ktorrent is the current default torrent client that we provide in > >>> > Kubuntu. > >>> > Now that we've transitioned to Plasma 5, it's no longer > >>> > buildable/installable in "Vivid". > >>> > > >>> > The upstream web site is down: http://ktorrent.org/ > >>> > >>> ^ that wouldn't be the qualifier on whether it suffers from dead > >>> upstream > >>> > >>> > I looked in KDE git and there's no sign of a KF5/Plasma 5 port: > >>> > https://projects.kde.org/projects/extragear/network/ktorrent/repositor > >>> > y > >>> > >>> ^ that wouldn't either > >>> > >>> > My conclusion is that ktorrent isn't an option for Vivid, so we either > >>> > need to stop shipping a torrent client or pick a different one. > >>> > >>> ^ those wouldn't be the primary options > >>> > >>> food for thought > >> > >> JR fixed it, so it's not an immediate issue. > >> > >> IMO it wasn't so much a dead upstream issue as a no longer works with > >> Plasma 5 > >> issue. The dead upstream just made that less likely to get better on > >> its own. > > > > my point is that there is no dead upstream, as no one tried to talk to > > upstream (nor brought it to the attention of the large kde developer > > community). > > The question is IMHO if you could ever consider an upstream dead. By > definition > this would mean that it would never become alive again. However, in Open > Source, > anybody can pick up the source and so a new group of people can take > over the > maintenance without anybody else being able to prevent it. > > So I would rephrase this question. How would you consider that a source > is > obsolete in the sense that there is a better one the replaces the first > one > and it does not make sense to put any kind of work in it anymore. Or, if > it > is still a valid choice, how to create the helpful flow of information > that > allows people to step forward to keep it maintained. Just an FYI Ktorrent is next on the Gardening team to do. We were able to get a new release with k3b and sparked new life into it. Please don't deem Ktorrent dead just yet. Scarlett -- Scarlett Clark Kubuntu Developer KDE Contributor IRC: sgclark Email: sgcl...@kubuntu.org signature.asc Description: This is a digitally signed message part. -- 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: Ktorrent Status/Replacement
On 2014-11-20 09:34, Harald Sitter wrote: On Thu, Nov 20, 2014 at 3:27 PM, Scott Kitterman wrote: On Thursday, November 20, 2014 03:17:33 PM Harald Sitter wrote: fwiw if only we had a policy to deal with dead upstreams On Mon, Nov 17, 2014 at 2:37 PM, Scott Kitterman wrote: > Ktorrent is the current default torrent client that we provide in Kubuntu. > Now that we've transitioned to Plasma 5, it's no longer > buildable/installable in "Vivid". > > The upstream web site is down: http://ktorrent.org/ ^ that wouldn't be the qualifier on whether it suffers from dead upstream > I looked in KDE git and there's no sign of a KF5/Plasma 5 port: > https://projects.kde.org/projects/extragear/network/ktorrent/repository ^ that wouldn't either > My conclusion is that ktorrent isn't an option for Vivid, so we either > need to stop shipping a torrent client or pick a different one. ^ those wouldn't be the primary options food for thought JR fixed it, so it's not an immediate issue. IMO it wasn't so much a dead upstream issue as a no longer works with Plasma 5 issue. The dead upstream just made that less likely to get better on its own. my point is that there is no dead upstream, as no one tried to talk to upstream (nor brought it to the attention of the large kde developer community). The question is IMHO if you could ever consider an upstream dead. By definition this would mean that it would never become alive again. However, in Open Source, anybody can pick up the source and so a new group of people can take over the maintenance without anybody else being able to prevent it. So I would rephrase this question. How would you consider that a source is obsolete in the sense that there is a better one the replaces the first one and it does not make sense to put any kind of work in it anymore. Or, if it is still a valid choice, how to create the helpful flow of information that allows people to step forward to keep it maintained. -- 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 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: Ktorrent Status/Replacement
On Thu, Nov 20, 2014 at 3:27 PM, Scott Kitterman wrote: > On Thursday, November 20, 2014 03:17:33 PM Harald Sitter wrote: >> fwiw if only we had a policy to deal with dead upstreams >> >> On Mon, Nov 17, 2014 at 2:37 PM, Scott Kitterman > wrote: >> > Ktorrent is the current default torrent client that we provide in Kubuntu. >> > Now that we've transitioned to Plasma 5, it's no longer >> > buildable/installable in "Vivid". >> > >> > The upstream web site is down: http://ktorrent.org/ >> >> ^ that wouldn't be the qualifier on whether it suffers from dead upstream >> >> > I looked in KDE git and there's no sign of a KF5/Plasma 5 port: >> > https://projects.kde.org/projects/extragear/network/ktorrent/repository >> >> ^ that wouldn't either >> >> > My conclusion is that ktorrent isn't an option for Vivid, so we either >> > need to stop shipping a torrent client or pick a different one. >> >> ^ those wouldn't be the primary options >> >> food for thought > > JR fixed it, so it's not an immediate issue. > > IMO it wasn't so much a dead upstream issue as a no longer works with Plasma 5 > issue. The dead upstream just made that less likely to get better on its own. my point is that there is no dead upstream, as no one tried to talk to upstream (nor brought it to the attention of the large kde developer community). -- 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
Re: Ktorrent Status/Replacement
On Thursday, November 20, 2014 03:17:33 PM Harald Sitter wrote: > fwiw if only we had a policy to deal with dead upstreams > > On Mon, Nov 17, 2014 at 2:37 PM, Scott Kitterman wrote: > > Ktorrent is the current default torrent client that we provide in Kubuntu. > > Now that we've transitioned to Plasma 5, it's no longer > > buildable/installable in "Vivid". > > > > The upstream web site is down: http://ktorrent.org/ > > ^ that wouldn't be the qualifier on whether it suffers from dead upstream > > > I looked in KDE git and there's no sign of a KF5/Plasma 5 port: > > https://projects.kde.org/projects/extragear/network/ktorrent/repository > > ^ that wouldn't either > > > My conclusion is that ktorrent isn't an option for Vivid, so we either > > need to stop shipping a torrent client or pick a different one. > > ^ those wouldn't be the primary options > > food for thought JR fixed it, so it's not an immediate issue. IMO it wasn't so much a dead upstream issue as a no longer works with Plasma 5 issue. The dead upstream just made that less likely to get better on its own. Scott K -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
New KDE Frameworks Versions as SRU
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. 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? Jonathan -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Ktorrent Status/Replacement
fwiw if only we had a policy to deal with dead upstreams On Mon, Nov 17, 2014 at 2:37 PM, Scott Kitterman wrote: > Ktorrent is the current default torrent client that we provide in Kubuntu. > Now that we've transitioned to Plasma 5, it's no longer buildable/installable > in "Vivid". > > The upstream web site is down: http://ktorrent.org/ ^ that wouldn't be the qualifier on whether it suffers from dead upstream > I looked in KDE git and there's no sign of a KF5/Plasma 5 port: > https://projects.kde.org/projects/extragear/network/ktorrent/repository ^ that wouldn't either > My conclusion is that ktorrent isn't an option for Vivid, so we either need to > stop shipping a torrent client or pick a different one. ^ those wouldn't be the primary options food for thought -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Munich Sprint
Some of us are going to a sprint in Munich tomorrow https://wiki.debian.org/BSP/2014/11/de/Munich We're due to be at the LiMux office at 18:00 for tea. I'm arriving at Munich MUC airport at 13:45 along with Harald. Rohan is getting there early in the day. If you'd like to go for an afternoon drink of something German then do get in touch. My phone number is +34 664 141 278 or maybe +447941938912 depending on which of my SIMs works better. Hasta mañana. Jonathan -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
