Re: Kioslave repos
On Wednesday 20 August 2014 11:38:12 Jonathan Riddell wrote: On Wed, Aug 20, 2014 at 12:28:30PM +0200, Aleix Pol wrote: On Tue, Aug 19, 2014 at 9:49 PM, David Faure fa...@kde.org wrote: On Tuesday 01 July 2014 22:25:15 Jonathan Riddell wrote: On Tue, Jul 01, 2014 at 11:25:11PM +0200, David Faure wrote: On Sunday 27 April 2014 19:35:37 I wrote: * place that repo in kde/ or kde/something in the projects.kde.org hierarchy, so that it gets released with the KDE Applications, NOT with the workspace product. Support for kio_fish/kio_sftp on Windows or Gnome desktops is one of the major selling points of Dolphin there, this is apps, not workspace. What happened to this? I see that kio-extras is in kde/workspace, while I believe it doesn't belong there. Does anyone disagree with my line of thought above? plasma-devel list may also have an opinion on this, sending there. Any news? No, but let's do this. I'll request a move of kio-extras [1] from kde/workspace to kde/runtime. Correct? +1 It's released with Plasma because there's currently no other releases to include it with. That is *extremely* strange thinking in my opinion. irony Should we also move dolphin to workspace because otherwise plasma gets released without a filemanager? /irony I can't see what's critical about having kio_sftp and friends in plasma right now. Or maybe this is about kio_trash, but that one will move to kio, as per the other thread. Once KDE Applications is releasing it can be released with that. I am strongly in favour of moving things to the right place in order to avoid creating a confusing mess. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Wed, Aug 20, 2014 at 12:48 PM, Luigi Toscano luigi.tosc...@tiscali.it wrote: On Wednesday 20 of August 2014 11:38:12 Jonathan Riddell wrote: On Wed, Aug 20, 2014 at 12:28:30PM +0200, Aleix Pol wrote: On Tue, Aug 19, 2014 at 9:49 PM, David Faure fa...@kde.org wrote: On Tuesday 01 July 2014 22:25:15 Jonathan Riddell wrote: On Tue, Jul 01, 2014 at 11:25:11PM +0200, David Faure wrote: On Sunday 27 April 2014 19:35:37 I wrote: * place that repo in kde/ or kde/something in the projects.kde.org hierarchy, so that it gets released with the KDE Applications, NOT with the workspace product. Support for kio_fish/kio_sftp on Windows or Gnome desktops is one of the major selling points of Dolphin there, this is apps, not workspace. What happened to this? I see that kio-extras is in kde/workspace, while I believe it doesn't belong there. Does anyone disagree with my line of thought above? plasma-devel list may also have an opinion on this, sending there. Any news? No, but let's do this. I'll request a move of kio-extras [1] from kde/workspace to kde/runtime. Correct? Aleix It's released with Plasma because there's currently no other releases to include it with. Once KDE Applications is releasing it can be released with that. And making a kde/runtime seems a sensible thing to do yes. Wasn't get rid of kde/runtime part of the big plan? If not, I think we could re-discuss the decision of where to put KCM modules, for example... Ciao -- Luigi Hm, fair enough. How does it sound to make kio-extras a framework then? It doesn't add new API but it does add run-time functionality to the applications. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On 24 Aug 2014, at 23:48 , Aleix Pol aleix...@kde.org wrote: Hm, fair enough. How does it sound to make kio-extras a framework then? It doesn't add new API but it does add run-time functionality to the applications. Oh, I thought kio-extras IS a framework already… ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On 24 Aug 2014, at 23:54 , Aleix Pol aleix...@kde.org wrote: On Sun, Aug 24, 2014 at 11:51 PM, Marko Käning mk-li...@email.de wrote: On 24 Aug 2014, at 23:48 , Aleix Pol aleix...@kde.org wrote: Hm, fair enough. How does it sound to make kio-extras a framework then? It doesn't add new API but it does add run-time functionality to the applications. Oh, I thought kio-extras IS a framework already… Thinking is only for brave people... ;) Well, it does build on OSX/CI already. Read the thread, it currently is under kde/workspace. Oh, I see, it was a cross-post then...___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tuesday 19 August 2014, David Faure wrote: Does anyone disagree with my line of thought above? plasma-devel list may also have an opinion on this, sending there. Any news? To me it should be in whatever place it is better for most people, and if there are use cases for it being outside workspace so be it. it would need i guess an area for runtime, but not necessarly workspace things -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tue, Aug 19, 2014 at 9:49 PM, David Faure fa...@kde.org wrote: On Tuesday 01 July 2014 22:25:15 Jonathan Riddell wrote: On Tue, Jul 01, 2014 at 11:25:11PM +0200, David Faure wrote: On Sunday 27 April 2014 19:35:37 I wrote: * place that repo in kde/ or kde/something in the projects.kde.org hierarchy, so that it gets released with the KDE Applications, NOT with the workspace product. Support for kio_fish/kio_sftp on Windows or Gnome desktops is one of the major selling points of Dolphin there, this is apps, not workspace. What happened to this? I see that kio-extras is in kde/workspace, while I believe it doesn't belong there. Does anyone disagree with my line of thought above? plasma-devel list may also have an opinion on this, sending there. Any news? No, but let's do this. I'll request a move of kio-extras [1] from kde/workspace to kde/runtime. Correct? Aleix [1] https://projects.kde.org/projects/kde/workspace/kio-extras ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Wed, Aug 20, 2014 at 12:28:30PM +0200, Aleix Pol wrote: On Tue, Aug 19, 2014 at 9:49 PM, David Faure fa...@kde.org wrote: On Tuesday 01 July 2014 22:25:15 Jonathan Riddell wrote: On Tue, Jul 01, 2014 at 11:25:11PM +0200, David Faure wrote: On Sunday 27 April 2014 19:35:37 I wrote: * place that repo in kde/ or kde/something in the projects.kde.org hierarchy, so that it gets released with the KDE Applications, NOT with the workspace product. Support for kio_fish/kio_sftp on Windows or Gnome desktops is one of the major selling points of Dolphin there, this is apps, not workspace. What happened to this? I see that kio-extras is in kde/workspace, while I believe it doesn't belong there. Does anyone disagree with my line of thought above? plasma-devel list may also have an opinion on this, sending there. Any news? No, but let's do this. I'll request a move of kio-extras [1] from kde/workspace to kde/runtime. Correct? Aleix It's released with Plasma because there's currently no other releases to include it with. Once KDE Applications is releasing it can be released with that. And making a kde/runtime seems a sensible thing to do yes. Jonathan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Wednesday 20 of August 2014 11:38:12 Jonathan Riddell wrote: On Wed, Aug 20, 2014 at 12:28:30PM +0200, Aleix Pol wrote: On Tue, Aug 19, 2014 at 9:49 PM, David Faure fa...@kde.org wrote: On Tuesday 01 July 2014 22:25:15 Jonathan Riddell wrote: On Tue, Jul 01, 2014 at 11:25:11PM +0200, David Faure wrote: On Sunday 27 April 2014 19:35:37 I wrote: * place that repo in kde/ or kde/something in the projects.kde.org hierarchy, so that it gets released with the KDE Applications, NOT with the workspace product. Support for kio_fish/kio_sftp on Windows or Gnome desktops is one of the major selling points of Dolphin there, this is apps, not workspace. What happened to this? I see that kio-extras is in kde/workspace, while I believe it doesn't belong there. Does anyone disagree with my line of thought above? plasma-devel list may also have an opinion on this, sending there. Any news? No, but let's do this. I'll request a move of kio-extras [1] from kde/workspace to kde/runtime. Correct? Aleix It's released with Plasma because there's currently no other releases to include it with. Once KDE Applications is releasing it can be released with that. And making a kde/runtime seems a sensible thing to do yes. Wasn't get rid of kde/runtime part of the big plan? If not, I think we could re-discuss the decision of where to put KCM modules, for example... Ciao -- Luigi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tuesday 01 July 2014 22:25:15 Jonathan Riddell wrote: On Tue, Jul 01, 2014 at 11:25:11PM +0200, David Faure wrote: On Sunday 27 April 2014 19:35:37 I wrote: * place that repo in kde/ or kde/something in the projects.kde.org hierarchy, so that it gets released with the KDE Applications, NOT with the workspace product. Support for kio_fish/kio_sftp on Windows or Gnome desktops is one of the major selling points of Dolphin there, this is apps, not workspace. What happened to this? I see that kio-extras is in kde/workspace, while I believe it doesn't belong there. Does anyone disagree with my line of thought above? plasma-devel list may also have an opinion on this, sending there. Any news? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Sunday 27 April 2014 19:35:37 I wrote: * place that repo in kde/ or kde/something in the projects.kde.org hierarchy, so that it gets released with the KDE Applications, NOT with the workspace product. Support for kio_fish/kio_sftp on Windows or Gnome desktops is one of the major selling points of Dolphin there, this is apps, not workspace. What happened to this? I see that kio-extras is in kde/workspace, while I believe it doesn't belong there. Does anyone disagree with my line of thought above? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tue, Jul 01, 2014 at 11:25:11PM +0200, David Faure wrote: On Sunday 27 April 2014 19:35:37 I wrote: * place that repo in kde/ or kde/something in the projects.kde.org hierarchy, so that it gets released with the KDE Applications, NOT with the workspace product. Support for kio_fish/kio_sftp on Windows or Gnome desktops is one of the major selling points of Dolphin there, this is apps, not workspace. What happened to this? I see that kio-extras is in kde/workspace, while I believe it doesn't belong there. Does anyone disagree with my line of thought above? plasma-devel list may also have an opinion on this, sending there. Jonathan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tuesday 08 April 2014 06:02:33 Àlex Fiestas wrote: On Monday 07 April 2014 23:27:33 Alex Merry wrote: Aleix wanted a separate thread for this, so here it is. The current runtime splitting plan says that ioslaves should be in three places: core ones (file, http, etc) in kio, other useful ones (archive, bookmarks, etc) in kioslaves, and curiosities (cgi, finger) in kioslave-extra. In my view, this is too many repos (and I apologise for not bringing it up sooner, but the last I'd seen on the list, only one repo outside kio was being suggested, and I hadn't realised the plan had changed). Moving things between repos is a *pain*, and I think Ben and Albert have a point about being over-eager to split things up. In this case, I think we should just have core things in kio, and everything else in kioslaves (or call it kio-extra-slaves, or whatever). Everything in that package should be optional, and distros can split it up if they really want, but I don't think we should split it. The reason for the split is that they are not used, not maintained and they are not of general interest. Few examples: kiosalves of interest: sftp fish smb ... kioslaves not of interest: settings (allows you to use dolphin/konqueror as systemsettings) cgi (allows you to execute cgi without having a web server) finger I personally do not want to have those not of interest or unmaintained kiosalves around, I do not want to maintain them, I do not want distros to ship them by default (which will happen for those distros that will pacakge the entire repository) etc. Maybe we can move them to unmaintain (there is such place in our git repos I think) or something like that, but I really think that kio_cgi does not belong near smb. Here's my take on this topic: * kill settings, cgi and finger * move kio_desktop to workspace * put the rest in a kio-extras repo (that part is done, I see) * place that repo in kde/ or kde/something in the projects.kde.org hierarchy, so that it gets released with the KDE Applications, NOT with the workspace product. Support for kio_fish/kio_sftp on Windows or Gnome desktops is one of the major selling points of Dolphin there, this is apps, not workspace. (I can help with the last task, moving on p.k.o, if everyone agrees) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Sunday 27 April 2014 15:39:05 David Faure wrote: On Tuesday 08 April 2014 06:02:33 Àlex Fiestas wrote: On Monday 07 April 2014 23:27:33 Alex Merry wrote: Aleix wanted a separate thread for this, so here it is. The current runtime splitting plan says that ioslaves should be in three places: core ones (file, http, etc) in kio, other useful ones (archive, bookmarks, etc) in kioslaves, and curiosities (cgi, finger) in kioslave-extra. In my view, this is too many repos (and I apologise for not bringing it up sooner, but the last I'd seen on the list, only one repo outside kio was being suggested, and I hadn't realised the plan had changed). Moving things between repos is a *pain*, and I think Ben and Albert have a point about being over-eager to split things up. In this case, I think we should just have core things in kio, and everything else in kioslaves (or call it kio-extra-slaves, or whatever). Everything in that package should be optional, and distros can split it up if they really want, but I don't think we should split it. The reason for the split is that they are not used, not maintained and they are not of general interest. Few examples: kiosalves of interest: sftp fish smb ... kioslaves not of interest: settings (allows you to use dolphin/konqueror as systemsettings) cgi (allows you to execute cgi without having a web server) finger I personally do not want to have those not of interest or unmaintained kiosalves around, I do not want to maintain them, I do not want distros to ship them by default (which will happen for those distros that will pacakge the entire repository) etc. Maybe we can move them to unmaintain (there is such place in our git repos I think) or something like that, but I really think that kio_cgi does not belong near smb. Here's my take on this topic: * kill settings, cgi and finger * move kio_desktop to workspace * put the rest in a kio-extras repo (that part is done, I see) * place that repo in kde/ or kde/something in the projects.kde.org hierarchy, so that it gets released with the KDE Applications, NOT with the workspace product. Support for kio_fish/kio_sftp on Windows or Gnome desktops is one of the major selling points of Dolphin there, this is apps, not workspace. (I can help with the last task, moving on p.k.o, if everyone agrees) I like that. It nicely solves the kind of limbo it is in ATM and avoids the tie to workspace. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Sun, Apr 27, 2014 at 3:39 PM, David Faure fa...@kde.org wrote: On Tuesday 08 April 2014 06:02:33 Àlex Fiestas wrote: On Monday 07 April 2014 23:27:33 Alex Merry wrote: Aleix wanted a separate thread for this, so here it is. The current runtime splitting plan says that ioslaves should be in three places: core ones (file, http, etc) in kio, other useful ones (archive, bookmarks, etc) in kioslaves, and curiosities (cgi, finger) in kioslave-extra. In my view, this is too many repos (and I apologise for not bringing it up sooner, but the last I'd seen on the list, only one repo outside kio was being suggested, and I hadn't realised the plan had changed). Moving things between repos is a *pain*, and I think Ben and Albert have a point about being over-eager to split things up. In this case, I think we should just have core things in kio, and everything else in kioslaves (or call it kio-extra-slaves, or whatever). Everything in that package should be optional, and distros can split it up if they really want, but I don't think we should split it. The reason for the split is that they are not used, not maintained and they are not of general interest. Few examples: kiosalves of interest: sftp fish smb ... kioslaves not of interest: settings (allows you to use dolphin/konqueror as systemsettings) cgi (allows you to execute cgi without having a web server) finger I personally do not want to have those not of interest or unmaintained kiosalves around, I do not want to maintain them, I do not want distros to ship them by default (which will happen for those distros that will pacakge the entire repository) etc. Maybe we can move them to unmaintain (there is such place in our git repos I think) or something like that, but I really think that kio_cgi does not belong near smb. Here's my take on this topic: * kill settings, cgi and finger * move kio_desktop to workspace * put the rest in a kio-extras repo (that part is done, I see) * place that repo in kde/ or kde/something in the projects.kde.org hierarchy, so that it gets released with the KDE Applications, NOT with the workspace product. Support for kio_fish/kio_sftp on Windows or Gnome desktops is one of the major selling points of Dolphin there, this is apps, not workspace. (I can help with the last task, moving on p.k.o, if everyone agrees) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Makes sense to me. +1 Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
The problem is manpower, we do not have the manpwoer to maintain half o the things we have in the workspace, most of the things in there are half-cooked or they do not even work (kglobalaccel kcm) and instead of taking a breath and decide what we want and what we do not want (like we did in the sprint) we are just blindly moving forward and making things compile that no developers care about. This has to stop. This must stop. I agree with your analysis of the problem but not with your solution. If it's broken, should not be shipped and is unmaintained then be bold and either delete it or move it to our dead code cemetery. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Friday 11 April 2014 01:33:54 Aurélien Gâteau wrote: The problem is manpower, we do not have the manpwoer to maintain half o the things we have in the workspace, most of the things in there are half-cooked or they do not even work (kglobalaccel kcm) and instead of taking a breath and decide what we want and what we do not want (like we did in the sprint) we are just blindly moving forward and making things compile that no developers care about. This has to stop. This must stop. I agree with your analysis of the problem but not with your solution. If it's broken, should not be shipped and is unmaintained then be bold and either delete it or move it to our dead code cemetery. I'm all for dead code cemetery, but where is it? signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Fri, Apr 11, 2014, at 1:51, Àlex Fiestas wrote: On Friday 11 April 2014 01:33:54 Aurélien Gâteau wrote: The problem is manpower, we do not have the manpwoer to maintain half o the things we have in the workspace, most of the things in there are half-cooked or they do not even work (kglobalaccel kcm) and instead of taking a breath and decide what we want and what we do not want (like we did in the sprint) we are just blindly moving forward and making things compile that no developers care about. This has to stop. This must stop. I agree with your analysis of the problem but not with your solution. If it's broken, should not be shipped and is unmaintained then be bold and either delete it or move it to our dead code cemetery. I'm all for dead code cemetery, but where is it? We used to have an unmaintained svn dir, but it seems we don't have a git equivalent :/ Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
Am Freitag, 11. April 2014, 02:21:22 schrieb Aurélien Gâteau: On Fri, Apr 11, 2014, at 1:51, Àlex Fiestas wrote: On Friday 11 April 2014 01:33:54 Aurélien Gâteau wrote: The problem is manpower, we do not have the manpwoer to maintain half o the things we have in the workspace, most of the things in there are half-cooked or they do not even work (kglobalaccel kcm) and instead of taking a breath and decide what we want and what we do not want (like we did in the sprint) we are just blindly moving forward and making things compile that no developers care about. This has to stop. This must stop. I agree with your analysis of the problem but not with your solution. If it's broken, should not be shipped and is unmaintained then be bold and either delete it or move it to our dead code cemetery. I'm all for dead code cemetery, but where is it? We used to have an unmaintained svn dir, but it seems we don't have a git equivalent :/ Of course we have that: https://projects.kde.org/projects/unmaintained -- Burkhard Lück ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
Hello, On Friday 11 April 2014 01:33:54 Aurélien Gâteau wrote: The problem is manpower, we do not have the manpwoer to maintain half o the things we have in the workspace, most of the things in there are half-cooked or they do not even work (kglobalaccel kcm) For the record, it works in 4 that particular one, I use it... and instead of taking a breath and decide what we want and what we do not want (like we did in the sprint) we are just blindly moving forward and making things compile that no developers care about. This has to stop. This must stop. I agree with your analysis of the problem but not with your solution. If it's broken, should not be shipped and is unmaintained then be bold and either delete it or move it to our dead code cemetery. ... and that's why I disagree with both the analysis and the solution. Because it seems the analysis is very weak in the first place. The fact that from one mail to the next we shift in different exhibited examples avoiding general rules is telling IMO. I'm concerned there's no criteria set but feelings (I don't want to maintain it because of its ugly face)[*]. That's the best way to create problems like our previous major workspace release. And I agree with what was previously said of not rubbing stuff under the carpet. I'm not saying nothing should be moved to the dead code area of course. It is justified to move code in such an area if it's broken *and* not causing important user regressions on removal. If it's just broken it should be repaired and eventually obsoleted responsibly later on. Regards. PS: Of course I could be totally wrong and there's been a strong analysis where general rules got set and you're in fact following that. Then it's just that I see no real evidence of it (which could be worsened by the way we structured our wikis). PPS: And obviously, even if I'm right, the product can turn out OK in the end by chance. That would still be taking a huge risk with one of the main community assets though, I'm all for reducing this kind of risks. [*] I admit we had it easier in kdelibs as lxr could help reduce the part of feelings and check our criteria... and even there we stumbled and screwed up a few times. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Thursday 10 April 2014 19:52:34 Àlex Fiestas wrote: So like I said in the sprint is it is something nice to have but it has to be maintained, fixed and polished and that won't happen before 2.0 and there is no reason to believe it will ever happen (since nobody at the sprint even knew what it was). A problem i'm seeing now in this thread, is that in january at the sprint not everybody was present. and the parts of the workspace, especially those dreaded (uhm, hystoric?;) ones are of interest really of everybody. So is reasonable some of the things decided there come as a surprise, or that many potential maintainers just completely missed thins. in an ideal world(tm) would probably had to be done in a breakout session at akademy, as in the only configuration most of the people that should be there are there. But since that wasn't possible, I'm proposing the following: On frameworks tuesdays (just to piggyback a day many people already have reserved to be on irc, another day may be planned if needed) we again go over the pieces, one by one, like we did at the sprint, and again search for maintainers for things that don't have yet. More important thing would be doing a priority list for things that really must be there and is vital they cannot regress and having those assigned to somebody first (obvious example, global shortcut editor) This of course makes sense if enough people are interested doing it. maybe i'm talking shit, i don't know ;) does it make sense? would somebody be interested in this adopt-a-pet thing? -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Wednesday 09 April 2014 11:57:37 Marco Martin wrote: On Wednesday 09 April 2014, Àlex Fiestas wrote: I'm against having anything in plasma-* without maintainer and even less if it is something that is known to have bugs (many) in KDE4. So we wither split it and hope somebody will give love to it or remove it. Not talking about that repo in particular, but... on the other hand, putting stuff in own micro repositories is as swiping under the carpet as leaving them in one of the main ones, if anything it ensures even more that it will go abandoned and unnoticed. If it's stuff that really nobody is even using and is safe to drop, that's ok (would be even ok to just delete it tough) but if is something that the user needs anyways and potentially causes regressions in the experience, it has to stay, and in the place that goes the least unnoticed. Developers being confortable with it, or even (gasp!) being actively maintained goes completely secondary behind the causing as less regressions as possible for the users. I guess you can leave the code there and just not add it to cmake, then we will end up like in kde-workspace form KDE4 with a bunch of code nobody even knows what it does. We need to sort the house and do spring cleaning and this is our chance to do so. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Thursday 10 April 2014 10:40:04 Àlex Fiestas wrote: On Wednesday 09 April 2014 11:57:37 Marco Martin wrote: On Wednesday 09 April 2014, Àlex Fiestas wrote: I'm against having anything in plasma-* without maintainer and even less if it is something that is known to have bugs (many) in KDE4. So we wither split it and hope somebody will give love to it or remove it. Not talking about that repo in particular, but... on the other hand, putting stuff in own micro repositories is as swiping under the carpet as leaving them in one of the main ones, if anything it ensures even more that it will go abandoned and unnoticed. If it's stuff that really nobody is even using and is safe to drop, that's ok (would be even ok to just delete it tough) but if is something that the user needs anyways and potentially causes regressions in the experience, it has to stay, and in the place that goes the least unnoticed. Developers being confortable with it, or even (gasp!) being actively maintained goes completely secondary behind the causing as less regressions as possible for the users. I guess you can leave the code there and just not add it to cmake, Huh? I hope you realize that's the same than putting it in a micro-repository no one builds... I think that Marco meant stay in the least unnoticed place *and* built by default (seemed obvious to me, although it was implicit). Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Thursday 10 April 2014, you wrote: in the second case, it's just a release blocker, and has to be enabled and ported, *even if* there won't be anyone maintaining it after that, it's a part of the workspace and needs to be released, (and yes, preferably in the plasma- workspace repo) if it's not yet, there will be no release until is ported and built. one concrete thing that may be done is to do a (yet another) sweep of the things that are from workspace/runtime and being move around, like was done in the sprint, but do it in this mailinglist with more people interested involved. so, the central thing this time will be is it necessary or will it cause significant regressions In this way we can make sure no stuff that has still valid use case (yes, even if all of the people working in the framework hate such component, that's irrelevant :p) is left unported (like a good example is the automounter, i would never use such a thing ever, never the less that's irrelevant and is an important component of a base workspace for too many users, no matter how buggy or unmaintained is) -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Thursday 10 April 2014 13:43:37 Marco Martin wrote: On Thursday 10 April 2014, Àlex Fiestas wrote: Developers being confortable with it, or even (gasp!) being actively maintained goes completely secondary behind the causing as less regressions as possible for the users. I guess you can leave the code there and just not add it to cmake, then we no, even that is the same problem (i did not explain enough), ie there are two cases: * it's not built and ported yet, likely noone will miss it * it's not built and ported yet, causes regressions in the first case, it can either be just killed or is fine the micro repo if someone steps up for maintainership in the second case, it's just a release blocker, and has to be enabled and ported, *even if* there won't be anyone maintaining it after that, it's a part of the workspace and needs to be released, (and yes, preferably in the plasma- workspace repo) if it's not yet, there will be no release until is ported and built. Thing is, in KDE4 it is broken, the model is all fucked up, some times it mounts the incorrect things or things that are already mounted (causing annoying dialogs) etc. So like I said in the sprint is it is something nice to have but it has to be maintained, fixed and polished and that won't happen before 2.0 and there is no reason to believe it will ever happen (since nobody at the sprint even knew what it was). signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Thursday 10 April 2014 14:42:37 Marco Martin wrote: On Thursday 10 April 2014, you wrote: in the second case, it's just a release blocker, and has to be enabled and ported, *even if* there won't be anyone maintaining it after that, it's a part of the workspace and needs to be released, (and yes, preferably in the plasma- workspace repo) if it's not yet, there will be no release until is ported and built. one concrete thing that may be done is to do a (yet another) sweep of the things that are from workspace/runtime and being move around, like was done in the sprint, but do it in this mailinglist with more people interested involved. so, the central thing this time will be is it necessary or will it cause significant regressions In this way we can make sure no stuff that has still valid use case (yes, even if all of the people working in the framework hate such component, that's irrelevant :p) is left unported (like a good example is the automounter, i would never use such a thing ever, never the less that's irrelevant and is an important component of a base workspace for too many users, no matter how buggy or unmaintained is) Even though going offtopic I will use this thread to say my mind since it seems that your PoV diverges from mine. The problem is manpower, we do not have the manpwoer to maintain half o the things we have in the workspace, most of the things in there are half-cooked or they do not even work (kglobalaccel kcm) and instead of taking a breath and decide what we want and what we do not want (like we did in the sprint) we are just blindly moving forward and making things compile that no developers care about. This has to stop. This must stop. This mess, this lack of quality is what makes KDE4 unpolished even after 6 years of development, we have plenty of features more than we can handle and we need to puts things in order. This video shows a bit of the things I feel: http://www.youtube.com/watch?v=CqY9l9qiFoA And this feeling is a constant while using kde4, some kde4 apps etc. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tuesday 08 April 2014 17:37:00 Kevin Ottens wrote: Good move. Pushed me toward looking a bit closer to this page, as obviously we didn't look close enough before (sorry about that), I might have a concern still: solid-deviceautomounter getting its own repository. It looks again like a completely leave behind or put in plasma-workspace (maybe not the kcm which is perhaps more plasma-desktop). With the uncertainty around it, I'd say its put in plasma-* until we got a replacement solution. I'm against having anything in plasma-* without maintainer and even less if it is something that is known to have bugs (many) in KDE4. So we wither split it and hope somebody will give love to it or remove it. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Wednesday 09 April 2014, Àlex Fiestas wrote: I'm against having anything in plasma-* without maintainer and even less if it is something that is known to have bugs (many) in KDE4. So we wither split it and hope somebody will give love to it or remove it. Not talking about that repo in particular, but... on the other hand, putting stuff in own micro repositories is as swiping under the carpet as leaving them in one of the main ones, if anything it ensures even more that it will go abandoned and unnoticed. If it's stuff that really nobody is even using and is safe to drop, that's ok (would be even ok to just delete it tough) but if is something that the user needs anyways and potentially causes regressions in the experience, it has to stay, and in the place that goes the least unnoticed. Developers being confortable with it, or even (gasp!) being actively maintained goes completely secondary behind the causing as less regressions as possible for the users. -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Wednesday 09 April 2014 11:57:37 Marco Martin wrote: On Wednesday 09 April 2014, Àlex Fiestas wrote: I'm against having anything in plasma-* without maintainer and even less if it is something that is known to have bugs (many) in KDE4. So we wither split it and hope somebody will give love to it or remove it. Not talking about that repo in particular, but... on the other hand, putting stuff in own micro repositories is as swiping under the carpet as leaving them in one of the main ones, if anything it ensures even more that it will go abandoned and unnoticed. If it's stuff that really nobody is even using and is safe to drop, that's ok (would be even ok to just delete it tough) Exactly. but if is something that the user needs anyways and potentially causes regressions in the experience, it has to stay, and in the place that goes the least unnoticed. Developers being confortable with it, or even (gasp!) being actively maintained goes completely secondary behind the causing as less regressions as possible for the users. I suddenly feel understood. :-) That's my worry with some of the recent splits in workspace land, they seem to be done without the user in mind or regressions in sight. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tue, Apr 8, 2014 at 7:57 AM, Kevin Ottens er...@kde.org wrote: Hello, On Monday 07 April 2014 23:27:33 Alex Merry wrote: Aleix wanted a separate thread for this, so here it is. The current runtime splitting plan says that ioslaves should be in three places: core ones (file, http, etc) in kio, other useful ones (archive, bookmarks, etc) in kioslaves, and curiosities (cgi, finger) in kioslave-extra. In my view, this is too many repos (and I apologise for not bringing it up sooner, but the last I'd seen on the list, only one repo outside kio was being suggested, and I hadn't realised the plan had changed). Moving things between repos is a *pain*, and I think Ben and Albert have a point about being over-eager to split things up. Yes, some of the splits I see in workspace land leave me wondering what were the rationale for them. But I can smell problems down the line. To clarify, I'm not necessarily a huge fan of the one repository per framework as we did *but* there was a justification for it. We're trying to target an extra audience which would benefit from it. So that's a necessary evil for KDE Frameworks if you want. I don't see that for the workspace. In this case, I think we should just have core things in kio, and everything else in kioslaves (or call it kio-extra-slaves, or whatever). Everything in that package should be optional, and distros can split it up if they really want, but I don't think we should split it. I totally agree there. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel The rationale is that we should never need to pull a Plasma Workspace to get an _application_ running. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
Hello, On Tuesday 08 April 2014 12:30:44 Aleix Pol wrote: The rationale is that we should never need to pull a Plasma Workspace to get an _application_ running. I'd argue the application is broken if that happens. :-) A regular application should only need KDE Frameworks and eventually other libraries (kdepimlibs, Qt, etc.) to run. If it needs direct implementation details about the workspace the application is badly designed. Of course that raises the question of what is part of the workspace... that doesn't give any indication on splitting though. No application was supposed to depend on kde-workspace before anyway, so I'd understand kicking out what's not needed in there anymore, I don't understand exploding it completely. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tue, Apr 8, 2014 at 12:55 PM, Kevin Ottens er...@kde.org wrote: Hello, On Tuesday 08 April 2014 12:30:44 Aleix Pol wrote: The rationale is that we should never need to pull a Plasma Workspace to get an _application_ running. I'd argue the application is broken if that happens. :-) A regular application should only need KDE Frameworks and eventually other libraries (kdepimlibs, Qt, etc.) to run. If it needs direct implementation details about the workspace the application is badly designed. Of course that raises the question of what is part of the workspace... that doesn't give any indication on splitting though. No application was supposed to depend on kde-workspace before anyway, so I'd understand kicking out what's not needed in there anymore, I don't understand exploding it completely. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel When I said applications shouldn't depend on Plasma Workspace I was referring to kde-runtime, where most kdelibs was relying on and so now do some frameworks. KHelpCenter was split into a different repository because applications will want to depend on it, same thing applies with most kioslaves and components. The rest has gone to plasma-*. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tue, Apr 8, 2014 at 12:27 AM, Alex Merry alex.me...@kde.org wrote: Aleix wanted a separate thread for this, so here it is. The current runtime splitting plan says that ioslaves should be in three places: core ones (file, http, etc) in kio, other useful ones (archive, bookmarks, etc) in kioslaves, and curiosities (cgi, finger) in kioslave-extra. In my view, this is too many repos (and I apologise for not bringing it up sooner, but the last I'd seen on the list, only one repo outside kio was being suggested, and I hadn't realised the plan had changed). Moving things between repos is a *pain*, and I think Ben and Albert have a point about being over-eager to split things up. In this case, I think we should just have core things in kio, and everything else in kioslaves (or call it kio-extra-slaves, or whatever). Everything in that package should be optional, and distros can split it up if they really want, but I don't think we should split it. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Given that premise, would you suggest having kurifilter-plugins in this repository as well? We can have a kio-extras repository with KIO::everything in it. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On 08/04/14 12:21, Aleix Pol wrote: Given that premise, would you suggest having kurifilter-plugins in this repository as well? We can have a kio-extras repository with KIO::everything in it. That seems reasonable to me. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Monday 07 April 2014 23:27:33 Alex Merry wrote: Aleix wanted a separate thread for this, so here it is. The current runtime splitting plan says that ioslaves should be in three places: core ones (file, http, etc) in kio, other useful ones (archive, bookmarks, etc) in kioslaves, and curiosities (cgi, finger) in kioslave-extra. In my view, this is too many repos (and I apologise for not bringing it up sooner, but the last I'd seen on the list, only one repo outside kio was being suggested, and I hadn't realised the plan had changed). Moving things between repos is a *pain*, and I think Ben and Albert have a point about being over-eager to split things up. In this case, I think we should just have core things in kio, and everything else in kioslaves (or call it kio-extra-slaves, or whatever). Everything in that package should be optional, and distros can split it up if they really want, but I don't think we should split it. The reason for the split is that they are not used, not maintained and they are not of general interest. Few examples: kiosalves of interest: sftp fish smb ... kioslaves not of interest: settings (allows you to use dolphin/konqueror as systemsettings) cgi (allows you to execute cgi without having a web server) finger I personally do not want to have those not of interest or unmaintained kiosalves around, I do not want to maintain them, I do not want distros to ship them by default (which will happen for those distros that will pacakge the entire repository) etc. Maybe we can move them to unmaintain (there is such place in our git repos I think) or something like that, but I really think that kio_cgi does not belong near smb. Cheers. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On 08/04/14 14:02, Àlex Fiestas wrote: I personally do not want to have those not of interest or unmaintained kiosalves around, I do not want to maintain them, I do not want distros to ship them by default (which will happen for those distros that will pacakge the entire repository) etc. Maybe we can move them to unmaintain (there is such place in our git repos I think) or something like that, but I really think that kio_cgi does not belong near smb. Well, I would say: discard them or include them. I know Albert was pushing not to get rid of code that still technically works, but I think you either have to go that route and put it in kioslaves/kio-extras/whatever (so that it will hopefully *keep* working), or declare it dead on the basis no-one cares enough to bother maintaining it. To a large extent, I would consider this the decision of whoever volunteers to maintain kio-extras (or whatever it gets called). Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tuesday 08 April 2014 14:31:51 Alex Merry wrote: On 08/04/14 14:02, Àlex Fiestas wrote: I personally do not want to have those not of interest or unmaintained kiosalves around, I do not want to maintain them, I do not want distros to ship them by default (which will happen for those distros that will pacakge the entire repository) etc. Maybe we can move them to unmaintain (there is such place in our git repos I think) or something like that, but I really think that kio_cgi does not belong near smb. Well, I would say: discard them or include them. I know Albert was pushing not to get rid of code that still technically works, but I think you either have to go that route and put it in kioslaves/kio-extras/whatever (so that it will hopefully *keep* working), or declare it dead on the basis no-one cares enough to bother maintaining it. To a large extent, I would consider this the decision of whoever volunteers to maintain kio-extras (or whatever it gets called). At least that makes more sense than spawning repositories like rabbits. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tue, Apr 8, 2014 at 1:55 PM, Alex Merry alex.me...@kde.org wrote: On 08/04/14 12:21, Aleix Pol wrote: Given that premise, would you suggest having kurifilter-plugins in this repository as well? We can have a kio-extras repository with KIO::everything in it. That seems reasonable to me. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Right, I updated the runtime splitting wiki page with this [1], by delaying to the futurible maintainer of the kio-extras the decision of what kioslaves to deprecate. I'll proceed and request kio-extras tomorrow if nobody has a strong argument against. Aleix [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tuesday 08 April 2014 14:31:51 Alex Merry wrote: Well, I would say: discard them or include them. I know Albert was pushing not to get rid of code that still technically works, but I think you either have to go that route and put it in kioslaves/kio-extras/whatever (so that it will hopefully *keep* working), or declare it dead on the basis no-one cares enough to bother maintaining it. To a large extent, I would consider this the decision of whoever volunteers to maintain kio-extras (or whatever it gets called). So, any takers? we need a maintainer. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Tuesday 08 April 2014 17:09:53 Aleix Pol wrote: Right, I updated the runtime splitting wiki page with this [1], by delaying to the futurible maintainer of the kio-extras the decision of what kioslaves to deprecate. Good move. Pushed me toward looking a bit closer to this page, as obviously we didn't look close enough before (sorry about that), I might have a concern still: solid-deviceautomounter getting its own repository. It looks again like a completely leave behind or put in plasma-workspace (maybe not the kcm which is perhaps more plasma-desktop). With the uncertainty around it, I'd say its put in plasma-* until we got a replacement solution. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Mon, April 7, 2014 23:27:33 Alex Merry wrote: Moving things between repos is a *pain*, and I think Ben and Albert have a point about being over-eager to split things up. In this case, I think we should just have core things in kio, and everything else in kioslaves (or call it kio-extra-slaves, or whatever). Everything in that package should be optional, and distros can split it up if they really want, but I don't think we should split it. I fall firmly in whatever is easiest for everyone, but there are some ioslaves in kdesdk-kioslaves that would also need to move to whatever the extra repo happens to be, if we're trying to combine these all into 2-3 repos. Regards, - Michael Pyne ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
Hello, On Monday 07 April 2014 23:27:33 Alex Merry wrote: Aleix wanted a separate thread for this, so here it is. The current runtime splitting plan says that ioslaves should be in three places: core ones (file, http, etc) in kio, other useful ones (archive, bookmarks, etc) in kioslaves, and curiosities (cgi, finger) in kioslave-extra. In my view, this is too many repos (and I apologise for not bringing it up sooner, but the last I'd seen on the list, only one repo outside kio was being suggested, and I hadn't realised the plan had changed). Moving things between repos is a *pain*, and I think Ben and Albert have a point about being over-eager to split things up. Yes, some of the splits I see in workspace land leave me wondering what were the rationale for them. But I can smell problems down the line. To clarify, I'm not necessarily a huge fan of the one repository per framework as we did *but* there was a justification for it. We're trying to target an extra audience which would benefit from it. So that's a necessary evil for KDE Frameworks if you want. I don't see that for the workspace. In this case, I think we should just have core things in kio, and everything else in kioslaves (or call it kio-extra-slaves, or whatever). Everything in that package should be optional, and distros can split it up if they really want, but I don't think we should split it. I totally agree there. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
