Re: [kde-community] Closing the kde-core-devel mailing list
Am Mittwoch, 27. August 2014, 07.24:04 schrieb Thiago Macieira: Morning Thiago [snip] I'm not asking we encourage that. But I am saying that: * we need a place for discussion to happen if it happens (it will) Yes, absolutely. Why not kde-devel. What else than the 15+ history speaks against it? * no one but KDE developers will use the kde-devel mailing list Ok, but if you use KDE Frameworks as a developer you're a KDE developer. The KDE community has no clear borders. Some people work on KDE Frameworks and thus core libraries, some people use these Frameworks and everybody is a KDE developer and part of the community. griits Mario ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On 27.08.2014 07:11, Aaron J. Seigo wrote: The way I've seen the goal for years is something like this: * applications should run great everywhere they can * applications deliver an even *better* experience when paired with Plasma You know, a little both/and :) +1, yeah :) Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Wednesday 27 August 2014 07:51:54 Laszlo Papp wrote: My suggestion: use qt-inter...@qt-project.org for supporting people who want to just use KF5, without developing it. I would understand that suggestion if the kde frameworks became official Qt 5 add-ons, although even then one could say to have modularized lists rather than a catch-all list where the relevance to your interest might be X % or lower. I think it is ok not to have a catch-all mailing list for everything that may end up in inqclude, i.e. qt libraries. It's not going to become official, as KF5 will not use Gerrit and will not adopt the Qt CLA. However, I don't see a problem answering questions about KF5, Qxt, Qwt and other Qt-based libraries in qt-interest. In fact, I encourage it because it increases the Qt ecosystem and attractiveness. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, August 12, 2014 17.31:11 Kevin Krammer wrote: On Tuesday, 2014-08-12, 16:40:36, Aaron J. Seigo wrote: On Tuesday, August 5, 2014 21.28:14 Kevin Krammer wrote: k-c-d is the list to for things that happen in development, like kde-review requests, inter-module coordination, etc. It is more like a kde-community-technical list. review requests probably should be going elsewhere; they make following actual discussion not about specific patches more difficult. I didn't mean review request as in reviewboard notifications. I meant request for review of things moving into kde-review. Ok :) So, kde-review requests ... There are two broad categories: * module-specific * lone projects An example of a module-specific category woudl be a new Calligra application. Does that benefit more from being announced on k-c-d, or on the Calligra devel ml? Similarly for a new framework / library: that probably makes most sense to request review from the Frameworks team since it needs to follow a rather specific and highly prescribed set of standards. I don't think it makes any more sense to announce a new framework is available for review on the Calligra list than it does to announce a new Calligra application on k-c-d. This pattern repeats with kdepim, plasma, edu, games, etc.. Lone projects, ones that don't fit into any particularly active existing community, need a place to announce, of course. Also, i18n/l10n probably wants to be able to track such things. If kde-devel@ is the mailing list for discussing use of KDE frameworks/libraries (as opposed to the development of them), then this would be a natural place for that to occur. It would also bring some additional focus and energy to kde-devel@ that is quite on-topic for that list. My suggestion therefore is to move kde-review announcements to kde-devel@, allowing k-c-d to focus on frameworks development and coordination. inter-module coordination ... should that not happen on the relevant module lists? You mean multiposting to several lists, potentially ones one is not subscribed to? Ah, we have a terminology issue. When I hear inter-module I hear something that affects 2-3 specific modules at the application level; you seem to be using it as a loose synonym for frameworks. Example: If it involves, say, KDE Edu and KDE Games considering adopting a common QML UI strategy (random, but potentially realistic, example) then cross-posting to those lists seems quite sane. In such cases, k-c-d is not the best possible venue, though I see it being used for that from time to time. Another example, this time yours: Lets take for example my inquiry on interest for a scripting BoF. I could have posted that to all module development lists, I am sure posting to kde-core-devel was the better choice. Yes, k-c-d is perfect for that kind of thing; pan-KDE-software scripting is a frameworks issue. I don't see that as inter-module discussion any more than kcoreaddons, threadweaver, or any other frameworks level technology is. the reason kde-devel exists separately from kde-core-devel is to provide a place for developers working with KDE libraries and applications that doesn't also carry discussion related to work ongoing in kdelibs. Sure, but asking questions about how to use frameworks will end up on the frameworks list, because that's the most obvious name for people looking for help on frameworks. agreed; my suggestion is that we already have these lists: kde-core-devel and kde-devel. frameworks-devel ought to be closed and merged back into k-c-d from whence it was forked with the r-b traffic going to a new list. If we feel that this will be a problem we'll need frameworks users. we already have that: kde-devel@ -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tue, Aug 26, 2014 at 11:34 AM, Aaron J. Seigo ase...@kde.org wrote: Sure, but asking questions about how to use frameworks will end up on the frameworks list, because that's the most obvious name for people looking for help on frameworks. agreed; my suggestion is that we already have these lists: kde-core-devel and kde-devel. frameworks-devel ought to be closed and merged back into k-c-d from whence it was forked with the r-b traffic going to a new list. If we feel that this will be a problem we'll need frameworks users. we already have that: kde-devel@ If I was a developer using frameworks for my project with the knowledge of KDE is that Qt linux destkop (which is quite common), I would see kde-devel as list for KDE (the desktop) development things. If I knew the newer KDE is the community, I would still think it's a list for KDE folks discussing KDE stuff. On the other hand, list with kde-frameworks-* gives clear indication what's going on there and what's its purpose. A mailing list for outside (non-KDE) developers should imo be created ; forcing those developers onto broad KDE mailing lists can make people quite reluctant to use it as it may feel like they have to join some KDE development stuff, which they are not interested in, while all they need is an answer to their question. We want frameworks to spread throughout the world and we want people using it everywhere; I think we should have a proper, standalone support contact point for these developers, which is not loaded with other KDE devel stuff. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
Am Dienstag, 26. August 2014, 12.34:35 schrieb Martin Klapetek: Morning Martin We can have the perfectly named mailing list (whatever that means) but that is not going to get people using frameworks, which is at the core of your contention. To achieve the goal of more people using KDE frameworks something very different from a perfectly named mailing list is required. That's not what I implied though, I just said that I think we should have a dedicated mailing list for frameworks users, in no way I said it will get us more users. And I still think that dedicated frameworks support mailing list would be better than general purpose kde-devel. Just out of curiosity - why do you think having a dedicated ML purely for frameworks users would be such a bad idea? This question is not directed to me but let me try to answer anyway: Because that's exactly what kde-devel is. kde-devel is the mailing list where technical/software development in the KDE community happens. And as where mostly using kdelibs/KDE Frameworks 5 and Qt as the base for our software this is the KDE Frameworks user list and nothing else. For Plasma development (or KDE's Desktop) there is plasma-devel and for certain KDE apps and modules with other lists but what else should be discussed on kde-devel then the usage of KDE Frameworks? Best regards Mario ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, 2014-08-26, 12:02:27, Aaron J. Seigo wrote: On Tuesday, August 12, 2014 21.23:54 Kevin Ottens wrote: For instance, Kevin Krammer's example of having a mean of contacting largely for gauging the need of a scripting BoF is spot on. I hope it won't get to that point, but k-c-d would still have value if it was the only kind of traffic on it. How is a pan-KDE scripting BoF not a frameworks topic? It is mostly an application development topic, it becomes a frameworks topic if there is a need to create a framework for sharing stuff. In this specific case that's true, but not necessarily always. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, 2014-08-26, 11:34:20, Aaron J. Seigo wrote: On Tuesday, August 12, 2014 17.31:11 Kevin Krammer wrote: On Tuesday, 2014-08-12, 16:40:36, Aaron J. Seigo wrote: On Tuesday, August 5, 2014 21.28:14 Kevin Krammer wrote: review requests probably should be going elsewhere; they make following actual discussion not about specific patches more difficult. I didn't mean review request as in reviewboard notifications. I meant request for review of things moving into kde-review. Ok :) So, kde-review requests ... There are two broad categories: * module-specific * lone projects An example of a module-specific category woudl be a new Calligra application. Does that benefit more from being announced on k-c-d, or on the Calligra devel ml? I think the reason these review request go to the general list is that more people would like to help with reviewing them, e.g. Albert is always looking at i18n issues. We can either subscribe Albert to all module lists or require that review requests are posted to multiple lists. Or keep it simple for everyone and post to the shared development list. If kde-devel@ is the mailing list for discussing use of KDE frameworks/libraries (as opposed to the development of them), then this would be a natural place for that to occur. It would also bring some additional focus and energy to kde-devel@ that is quite on-topic for that list. My suggestion therefore is to move kde-review announcements to kde-devel@, allowing k-c-d to focus on frameworks development and coordination. That is also an option. kde-devel is not as noisy as it used to be, so all developers could rejoin it. inter-module coordination ... should that not happen on the relevant module lists? You mean multiposting to several lists, potentially ones one is not subscribed to? Ah, we have a terminology issue. When I hear inter-module I hear something that affects 2-3 specific modules at the application level; you seem to be using it as a loose synonym for frameworks. No, I mean the former. Application modules. Another example, this time yours: Lets take for example my inquiry on interest for a scripting BoF. I could have posted that to all module development lists, I am sure posting to kde-core-devel was the better choice. Yes, k-c-d is perfect for that kind of thing; pan-KDE-software scripting is a frameworks issue. I don't see that as inter-module discussion any more than kcoreaddons, threadweaver, or any other frameworks level technology is. Only if it involves a (potential) framework. In this this is incidentally true. If the scope of the BoF would just be gathering best pratices, I would have had to post to plasma-devel, kdepim, kwrite-devel, kwin-devel, kde-edu, kde- games-devel, calligra-devel and those are just the ones I can think of right now. I am not even subscribed to all of these, I am sure the respective list moderators would be thrilled to get tons of moderation requests. the reason kde-devel exists separately from kde-core-devel is to provide a place for developers working with KDE libraries and applications that doesn't also carry discussion related to work ongoing in kdelibs. Sure, but asking questions about how to use frameworks will end up on the frameworks list, because that's the most obvious name for people looking for help on frameworks. agreed; my suggestion is that we already have these lists: kde-core-devel and kde-devel. frameworks-devel ought to be closed and merged back into k-c-d from whence it was forked with the r-b traffic going to a new list. If we feel that this will be a problem we'll need frameworks users. we already have that: kde-devel@ Hence me writing if. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, August 26, 2014 13.39:46 Kevin Krammer wrote: Only if it involves a (potential) framework. In this this is incidentally true. If the scope of the BoF would just be gathering best pratices, I would have At risk of repeating myself in this thread: the definition of frameworks is being used in a fashion that is too narrow to be useful. If the scripting BoF never results in a physical git repository that joins KDE Framework, but only results in a best practice to be adopted by the Frameworks audience, then it ought to be on-topic for the frameworks devel list. It should, after all, be reflected in KDE Frameworks as well as the applications above it. .. and what of the applications? At least one person from each KDE development team which uses frameworks ought to be on the frameworks devel mailing list, if only to keep frameworks devel on track for the needs of the wider audience of application developers. If that assumption is wrong, then KDE is going to have some serious problems on its hands in short order; but I suspect it is not at all off the mark and you ought to be able to announce your BoF on a k-c-d that is dedicated primarily to frameworks-as-a-product and reach your intended audience. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, August 26, 2014 13.28:56 Kevin Krammer wrote: On Tuesday, 2014-08-26, 12:02:27, Aaron J. Seigo wrote: On Tuesday, August 12, 2014 21.23:54 Kevin Ottens wrote: For instance, Kevin Krammer's example of having a mean of contacting largely for gauging the need of a scripting BoF is spot on. I hope it won't get to that point, but k-c-d would still have value if it was the only kind of traffic on it. How is a pan-KDE scripting BoF not a frameworks topic? It is mostly an application development topic, it becomes a frameworks topic if there is a need to create a framework for sharing stuff. Stuff means more than code. A best practice is shared stuff; a community-wide policy is shared stuff. The difference between having an agreed upon best practice or policy and a code repository is academic; it requires the same people to buy into it and provide input. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, 2014-08-26, 16:15:56, Aaron J. Seigo wrote: On Tuesday, August 26, 2014 13.28:56 Kevin Krammer wrote: On Tuesday, 2014-08-26, 12:02:27, Aaron J. Seigo wrote: On Tuesday, August 12, 2014 21.23:54 Kevin Ottens wrote: For instance, Kevin Krammer's example of having a mean of contacting largely for gauging the need of a scripting BoF is spot on. I hope it won't get to that point, but k-c-d would still have value if it was the only kind of traffic on it. How is a pan-KDE scripting BoF not a frameworks topic? It is mostly an application development topic, it becomes a frameworks topic if there is a need to create a framework for sharing stuff. Stuff means more than code. A best practice is shared stuff; a community-wide policy is shared stuff. The difference between having an agreed upon best practice or policy and a code repository is academic; it requires the same people to buy into it and provide input. Ok, sure, if everything development related is a frameworks topic, then this is also a framework topic. I used frameworks in the sense of being related to KDE frameworks products as in contrast to KDE application products. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday 26 August 2014 15:28:09 Aaron J. Seigo wrote: Simple frameworks support list for random people who are not involved with KDE in any way and don't care about development (of any kind) inside of the community, but are just looking for support and possibly willing to offer support too, Yes, that's what kde-devel is supposed to be for. If we take away the review board email, much of the traffic is exactly that. My suggestion: use qt-inter...@qt-project.org for supporting people who want to just use KF5, without developing it. That would leave kde-devel for what it's been used for the past 15 years: discussing development of applications that are tightly integrated with KDE's desktop environment (i.e., Plasma desktop). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday 26 August 2014 17:17:43 Kevin Krammer wrote: On Tuesday, 2014-08-26, 16:15:56, Aaron J. Seigo wrote: Stuff means more than code. A best practice is shared stuff; a community-wide policy is shared stuff. The difference between having an agreed upon best practice or policy and a code repository is academic; it requires the same people to buy into it and provide input. Ok, sure, if everything development related is a frameworks topic, then this is also a framework topic. I used frameworks in the sense of being related to KDE frameworks products as in contrast to KDE application products. Although your dichotomy makes sense, I think I see the point Aaron is trying to make (any wrong paraphrasing will be totally my fault): Even if that's a KDE application development topic, as long at it spans a large enough set of applications, then it is relevant to occur where KDE Frameworks discussion occur. Of course the devil hides in the large enough definition. But we can probably rely on common sense and a firm list moderator/referee for that. :-) If understood that correctly it kind of make sense too. It's a good way to fix the disconnect between KDE application developers and kdeli^WKF5 developers which occurred when 4.0 got released. We made a tiny progress in that regard during the transition cycle, but we have to be careful to not get back to the starting point now that the transition is well engaged and applications started porting. Also even best practices can lead to finding holes in Qt or KF5... fixing those is clearly something in the realm of KDE Frameworks (as a Qt contribution or working toward a new framework). I was leaning toward having k-f-d for people interested in KDE Frameworks only... but seeing Aaron's argument, I think I'd be ready to change my position provided we have the following guarantees: * k-d is really about people asking questions on *using* the frameworks (our qt-interest if you will); * k-c-d is really about KF5 development and large enough cross KDE applications discussions. We did a bad job in the past at ensuring that. If we get a clear definition of what's allowed on both list and a couple of people actively monitoring the lists to redirect lost souls then I'm fine giving a try to that model again. BTW, Kevin, to me you look like a very good candidate for such a role. :-) In the spirit of my previous bullet point list, here is an alternative scenario assuming my rambling above is correct (it also takes into account the evolution of my thinking about review board): 1) Don't close k-f-d or k-c-d; 2) Restate the purpose of our k-c-d and k-d (probably on wiki) with guidelines on what's acceptable there; 3) Appoint moderators/curators/referees to deal with k-c-d and k-d using the new guidelines; 3) Move all review board traffic to a kde-reviewboard list (it'd make sense to deal with it just like commits in fact, they are proto-commits after all); 4) Wait for the first KDE Frameworks release containing kdepimlibs in full; 5) Close k-f-d in favor of k-c-d. 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-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday 26 August 2014 09:29:02 Thiago Macieira wrote: On Tuesday 26 August 2014 15:28:09 Aaron J. Seigo wrote: Simple frameworks support list for random people who are not involved with KDE in any way and don't care about development (of any kind) inside of the community, but are just looking for support and possibly willing to offer support too, Yes, that's what kde-devel is supposed to be for. If we take away the review board email, much of the traffic is exactly that. My suggestion: use qt-inter...@qt-project.org for supporting people who want to just use KF5, without developing it. That would leave kde-devel for what it's been used for the past 15 years: discussing development of applications that are tightly integrated with KDE's desktop environment (i.e., Plasma desktop). I like that suggestion! -- Milian Wolff m...@milianw.de http://milianw.de ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On 26.08.2014 22:05, Milian Wolff wrote: That would leave kde-devel for what it's been used for the past 15 years: discussing development of applications that are tightly integrated with KDE's desktop environment (i.e., Plasma desktop). I like that suggestion! My 2 cents: KDE is a the name of a community that makes a whole bunch of things, chiefly among them right now: * A set of libraries/frameworks that complement Qt and help with building applications and workspaces that run nicely on a variety of systems (and within a variety of work- spaces, in case of the applications). * A set of workspaces, taking advantage of the above. * A set of applications that integrate well with the above thanks to the prowess of those frameworks, but also inte- grate well with other workspaces. It follows from this that kde-devel (= KDE development) is a bad name for discussing development of applications that are tightly integrated with Plasma, for two reasons: * It's just one of the many development-type activities that projects within KDE do. * Thanks to excellent layering, much of tightly integra- ting with Plasma doesn't happen on the application level. As a broader theme, I'm annoyed whenever we start this kind of jealous-guarding behavior vis-a-vis apps must be tight- ly integrated with Plasma. We don't need to behave this way, it's not necessary, and sometimes it's holding us back. Our goal should be to deliver value to users. There are many ways KDE provides value to users today, and a lot of those don't use Plasma. KDE provides value to users when they use our applications in Gnome or on Windows. KDE pro- vides value to users when they use an application that was built with Qt, CMake or valgrind, because we've helped all of these projects in one way or another. None of these are related to using Plasma, but they're an important part of what makes KDE relevant in the world today. It's completely valid for an application project inside the KDE community to care greatly for its audience out- side the userbase of Plasma. We're still winning when ever someone uses something we've touched and improved in any way. Moreoever, we've engineered our community in such a way that such tight integration will regardless, both tech- nologically and socially: * On the tech side, we've layered things so that Plasma can be a driver of application integration by providing a Qt platform plugin. * On the social side, we have tenets like shared owner- ship, shared responsibility and broad write access, which means it's easy for those concerned with inte- gration to expand its scope across all of our projects. So yeah, let's please not make a write apps for Plasma mailing list. It doesn't fit what KDE is today - and that's a good thing, because our ambitions have become grander and our means to accomplish them have, too. NB: I mostly work on Plasma these days. Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, August 26, 2014 22.24:24 Eike Hein wrote: So yeah, let's please not make a write apps for Plasma mailing list. It doesn't fit what KDE is today - and that's a good thing, because our ambitions have become grander and our means to accomplish them have, too. I generally agree; that said, there is also nothing wrong with having good integration with Plasma. The key is to ensure it doesn't block the application from being used proficiently in other environments. The way I've seen the goal for years is something like this: * applications should run great everywhere they can * applications deliver an even *better* experience when paired with Plasma You know, a little both/and :) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday 26 August 2014 22:24:24 Eike Hein wrote: My 2 cents: KDE is a the name of a community that makes a whole bunch of things, chiefly among them right now: * A set of libraries/frameworks that complement Qt and help with building applications and workspaces that run nicely on a variety of systems (and within a variety of work- spaces, in case of the applications). * A set of workspaces, taking advantage of the above. * A set of applications that integrate well with the above thanks to the prowess of those frameworks, but also inte- grate well with other workspaces. It follows from this that kde-devel (= KDE development) is a bad name for discussing development of applications that are tightly integrated with Plasma, for two reasons: On a blue-sky situation, yes. My point is that the kde-devel mailing list has 15+ years of history. When k- c-d was created and split the development of kdelibs, what remained in kde- devel was general help about using the KDE libraries to write KDE applications that integrated with the KDE desktop. So yeah, let's please not make a write apps for Plasma mailing list. It doesn't fit what KDE is today - and that's a good thing, because our ambitions have become grander and our means to accomplish them have, too. I'm not asking we encourage that. But I am saying that: * we need a place for discussion to happen if it happens (it will) * no one but KDE developers will use the kde-devel mailing list -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, August 05, 2014 21:28:14 Kevin Krammer wrote: On Tuesday, 2014-08-05, 20:29:05, Albert Astals Cid wrote: El Dilluns, 4 d'agost de 2014, a les 20:36:44, Vishesh Handa va escriure: Random Idea: How about we close the k-c-d mailing list? It's main purpose used to be to discuss kdelibs changes, but now since we have kde-frameworks, the mailing list seems less useful. We already have kde-devel for other generic kde stuff. kde-core-devel main purpose may had been discuss kdelibs changes, but it has trascended that purspose a while ago. I agree with Albert. k-c-d is the list to for things that happen in development, like kde-review requests, inter-module coordination, etc. It is more like a kde-community-technical list. kde-devel is more a list for question regarding developing with the KDE platform. If there is really a need to fold one list with kde-frameworks its this one. Assuming you mean folding frameworks-devel, I'd agree. (We could merge these lists, of course.) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, August 5, 2014 21.28:14 Kevin Krammer wrote: k-c-d is the list to for things that happen in development, like kde-review requests, inter-module coordination, etc. It is more like a kde-community-technical list. review requests probably should be going elsewhere; they make following actual discussion not about specific patches more difficult. inter-module coordination ... should that not happen on the relevant module lists? kde-devel is more a list for question regarding developing with the KDE platform. If there is really a need to fold one list with kde-frameworks its this one. ... and then where do people go who want to ask questions about KDE-related development issues?[1] the reason kde-devel exists separately from kde-core-devel is to provide a place for developers working with KDE libraries and applications that doesn't also carry discussion related to work ongoing in kdelibs. putting frameworks discussion on kde-devel would just create a new displacement. perhaps it would make more sense to recall the purpose of each list, adapt to how the community is using reviewboard, and simplify rather than redefine and move around long-extant infrastructure? [1] from https://mail.kde.org/mailman/listinfo -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tue, Aug 12, 2014 at 3:40 PM, Aaron J. Seigo ase...@kde.org wrote: perhaps it would make more sense to recall the purpose of each list, adapt to how the community is using reviewboard, and simplify rather than redefine and move around long-extant infrastructure? +1 ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, 2014-08-12, 16:40:36, Aaron J. Seigo wrote: On Tuesday, August 5, 2014 21.28:14 Kevin Krammer wrote: k-c-d is the list to for things that happen in development, like kde-review requests, inter-module coordination, etc. It is more like a kde-community-technical list. review requests probably should be going elsewhere; they make following actual discussion not about specific patches more difficult. I didn't mean review request as in reviewboard notifications. I meant request for review of things moving into kde-review. inter-module coordination ... should that not happen on the relevant module lists? You mean multiposting to several lists, potentially ones one is not subscribed to? Doesn't sound very viable to me. Lets take for example my inquiry on interest for a scripting BoF. I could have posted that to all module development lists, I am sure posting to kde-core-devel was the better choice. kde-devel is more a list for question regarding developing with the KDE platform. If there is really a need to fold one list with kde-frameworks its this one. ... and then where do people go who want to ask questions about KDE-related development issues?[1] the reason kde-devel exists separately from kde-core-devel is to provide a place for developers working with KDE libraries and applications that doesn't also carry discussion related to work ongoing in kdelibs. Sure, but asking questions about how to use frameworks will end up on the frameworks list, because that's the most obvious name for people looking for help on frameworks. If we feel that this will be a problem we'll need frameworks users. putting frameworks discussion on kde-devel would just create a new displacement. Hence writing If there is really a need Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Monday 04 August 2014, Vishesh Handa wrote: Hello people Random Idea: How about we close the k-c-d mailing list? It's main purpose used to be to discuss kdelibs changes, but now since we have kde-frameworks, the mailing list seems less useful. We already have kde-devel for other generic kde stuff. hmm, I would maybe have seen a reason in doing like the other way around, closing kde-frameworks, merge the mails and move all on k-c-d, since frameworks is released and is the main target of development now -- Marco Martin ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Monday 04 August 2014 20:36:44 Vishesh Handa wrote: Hello people Random Idea: How about we close the k-c-d mailing list? It's main purpose used to be to discuss kdelibs changes, but now since we have kde-frameworks, the mailing list seems less useful. We already have kde-devel for other generic kde stuff. How about the opposite? Close the frameworks list and move that discussion back here, where it belongs. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
How about the opposite? Close the frameworks list and move that discussion back here, where it belongs. +1 For me, the frameworks list was useful for the work on splitting. Now, it is (kinda) business as usual, so we can all just return back to k-c-d. -- Cheerio, Ivan KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/ gpg key id: 850B6F76, keyserver.pgp.com ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
Hello, On Monday 04 August 2014 20:36:44 Vishesh Handa wrote: Random Idea: Heh, someone with too much time at hand? :-) Note that I generally find that fiddling with lists is generally generating quite some boring work across the board. How about we close the k-c-d mailing list? I think others voiced it but IMO it is a very bad idea... It's main purpose used to be to discuss kdelibs changes, but now since we have kde-frameworks, the mailing list seems less useful. We already have kde-devel for other generic kde stuff. ... which is based on wrong assumptions. As Albert et al. pointed out, k-c-d is used for community wide technical discussions: great plans touching several projects, tooling changes (the great scons vs cmake battle for instance), kdereview process tracking, reaching the core people (hence the name) aka most actives in the community (in their project or several projects). I like to define it as the town hall of the tech people in KDE. For some reason, the kdelibs related discussion still lingered there although it was becoming its own thing. Since KDE Frameworks started the noise level of that particular project would raise risking to drown the other useful communications of k-c-d, hence the creation of k-f-d to avoid that risk (there's another reason, see below). kde-devel is for people discussing general development. It's more the seeking general help area. (I think the above paragraphs should cover the recall the purpose of each list that Aaron was calling for, at least that's my version of it, I'd like to believe I've been around enough to not be too far off) So to get back to the original question, should be close kde-core-devel? I hope it's clear that bloody hell, no!!! Don't know how you'd feel about it, but for a community like our loosing its town hall that would be a disaster. For instance, Kevin Krammer's example of having a mean of contacting largely for gauging the need of a scripting BoF is spot on. I hope it won't get to that point, but k-c-d would still have value if it was the only kind of traffic on it. Some then argued that maybe we should close kde-frameworks-devel. That at least makes more sense to me. That said, I'm of the opinion we should keep it open. Remember above I mentioned there was another reason for its creation? I will get to it soon. ;-) Choosing to close k-f-d depends how you see its purpose... If you see its purpose as the mailing list for the kdelibs to KDE Frameworks transition *project*, then yes it can be closed once this transition is over (probably not now though, as kdepimlibs still didn't transition yet, so I'd expect the traffic to raise again). If you see its purpose as the mailing list for the KDE Frameworks *product* then it shouldn't be closed. I fall in the second category, because the reasoning for opening that list was first to avoid generating the noise on k-c-d during the transition (first reason already mentioned above) but also to have a place for third parties interested in KDE Frameworks only to participate and get informed (second reason). Obviously, it is too early to know if it is worth it having k-f-d for people interested in KDE Frameworks only as this audience didn't have time to form yet. Now, since it has been mentioned in the thread as well, there is the question of review board emails... I'm increasingly of the opinion that they shouldn't end up on k-f-d and k-c-d. I used to think otherwise, but it's becoming increasingly clear to me that it hinders other type of discussions. Which means that the third parties audience I was talking about won't even get a chance to form if we don't change that somehow. Back in the days we had bugzilla traffic on devel mailing lists, then it got moved away in specialized lists, it looks like the review board traffic should have the same fate. OK, it's longer than I wanted to so I will stop soon. Sorry for the length, but I thought that just coming with a bullet point of actions without the reasoning behind it would be disrespectful. Here is the bullet point list just in case it could be useful: 1) Don't close k-f-d or k-c-d; 2) Restate the purpose of our lists, maybe on wiki; 3) Move current review board traffic to some other list (kde-frameworks- reviews and kde-core-reviews perhaps? no strong opinion there); 4) Wait for the full kdepimlibs transition into KDE Frameworks; 5) Wait a few more months after that (something like six months, maybe longer, depends how fast we reroute reviews in fact); 6) If a third parties and new KF5 specific contributors audience formed on k- f-d then keep it, otherwise close it in favor of k-c-d[*]. Thanks for reading all the way down if you reached that line. ;-) Cheers. [*] Note that if that audience never forms we probably failed at something as the reason for modularizing aggressively was also to attract such new blood. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of
Re: [kde-community] Closing the kde-core-devel mailing list
On Monday, August 4, 2014 20.36:44 Vishesh Handa wrote: Random Idea: How about we close the k-c-d mailing list? It's main purpose used to be to discuss kdelibs changes, but now since we have kde-frameworks, the mailing list seems less useful. We already have kde-devel for other generic kde stuff. Not a good idea imho, and not only for the valid reasons others have already expressed in this thread. The frameworks list made sense for a while, when the idea was to not disrupt others with what was a pretty new and difficult effort, but that ceased being true a while back. Closing k-c-d would not only be a needless heaving of tradition overboard[1] we'd have to figure out what to do about everyone who is subscribed. Mass subscription is possible, but for what purpose? And who gets to deal with all the questions about it that will inevitably arise? What about all mentions in blogs, other emails and probably even devel documentation out there? A more real problem imho is that kde-frameworks-devel has become a review board ghetto. The vast majority of traffic is review board. k-c-d is only marginally better. This drowns out normal discussion and makes both lists less attractive to be on if you aren't a core contributor. This is not unlike how in the past using mailing lists for bug report CC's drowned out some lists. What would be nice imho is to have one list that is just review board requests (and move all the workspace related review requests to plasma-devel or to its own RB list) and another that is for actual non-patch-based discussion. Design discussion will be easier and it won't feel like standing in front of a fire hose when you join k-c-d or kde-frameworks-devel just because you want to get a bit involved. [1] culture matters, and culture centers around customs -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
El Dilluns, 4 d'agost de 2014, a les 20:36:44, Vishesh Handa va escriure: Hello people Random Idea: How about we close the k-c-d mailing list? It's main purpose used to be to discuss kdelibs changes, but now since we have kde-frameworks, the mailing list seems less useful. We already have kde-devel for other generic kde stuff. kde-core-devel main purpose may had been discuss kdelibs changes, but it has trascended that purspose a while ago. Let's see email threads that were sent here that don't belong to frameworks- devel, please tell me what list would replace k-c-d in this regard * Pushing AppStream data to KDE project's master branches * KDE Applications December 2014 release: which apps are targeting Qt4/Qt5? * Oxygen Fonts kdereview * Default wallpapers should go in svn or git? * Move of KXStitch to Extragear/Graphics * Kronometer now in KDE Review * Move of SymbolEditor to Extragear/Graphics * Moving plasma-nm to extragear * Talks @Akademy * KBibTeX in KDE Review * Freedesktop summit 2014 * kde-workspace split incoming! As you see these have nothing to do with kdelibs. Sure i understand lib development moved to frameworks-devel, that's fine, but until you have a place to discuss core stuff I don't see why we should close our core-devel list. Cheers, Albert ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, 2014-08-05, 20:29:05, Albert Astals Cid wrote: El Dilluns, 4 d'agost de 2014, a les 20:36:44, Vishesh Handa va escriure: Hello people Random Idea: How about we close the k-c-d mailing list? It's main purpose used to be to discuss kdelibs changes, but now since we have kde-frameworks, the mailing list seems less useful. We already have kde-devel for other generic kde stuff. kde-core-devel main purpose may had been discuss kdelibs changes, but it has trascended that purspose a while ago. I agree with Albert. k-c-d is the list to for things that happen in development, like kde-review requests, inter-module coordination, etc. It is more like a kde-community-technical list. kde-devel is more a list for question regarding developing with the KDE platform. If there is really a need to fold one list with kde-frameworks its this one. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] Closing the kde-core-devel mailing list
Hello people Random Idea: How about we close the k-c-d mailing list? It's main purpose used to be to discuss kdelibs changes, but now since we have kde-frameworks, the mailing list seems less useful. We already have kde-devel for other generic kde stuff. -- Vishesh Handa ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Closing the kde-core-devel mailing list
On Monday 04 August 2014 20:36:44 Vishesh Handa wrote: Hello people Random Idea: How about we close the k-c-d mailing list? It's main purpose used to be to discuss kdelibs changes, but now since we have kde-frameworks, the mailing list seems less useful. We already have kde-devel for other generic kde stuff. So far, kdelibs is still open for patches, no? So I'd say let's keep it until we stop accepting patches for kdelibs. Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community