Re: Instagram Account
On Mon, Mar 23, 2020 at 8:00 AM Jonathan Riddell wrote: > Me and Niccolo (veggero) have set up an instagram account for KDE. It > feels like a fun new way to engage with some of our users. Instagram is > based on pictures of pretty people and places so screenshots are cool there > but will likely bore the audience so we're keen to have pics of KDE doing > stuff. > > https://www.instagram.com/kdecommunity/ > > So send me your pics of doing KDE activities. > Please verify the source and license of whatever you get sent. The recent "Kubuntu rockstars" photo is mine, I don't know where that photo was downloaded from, but whenever I published my KDE-events photos they were always under CC-BY-SA, that particular Instagram post does not follow this license. Regardless, it'd be nice to always credit the people who took the photos, much like we always credit code and other contributions. Cheers -- Martin Klapetek
Re: Planet KDE posts not about KDE (was: Re: Please don't make planet.kde.org into a politics feed)
On Tue, Dec 10, 2019 at 8:01 PM Philippe Cloutier wrote: > Le 2019-12-05 à 10:45, Nate Graham a écrit : > > > > > > On 12/5/19 8:01 AM, Dominik Haumann wrote: > >> On Thu, Dec 5, 2019 at 1:24 PM Eike Hein wrote: > >>> But they don't, so your calculation is about solving a problem that > >>> doesn't currently exist. > >> > >> +1 > >> > > > > +2, let's propose fixing the problem when there actually is a problem, > > not when we suspect that there might at some future point be a problem > > if people don't behave well. > > > I'm afraid the problem is already there. The problem starts from the > moment a member posts an unrelated post, when someone who is not > interested in it starts reading. > But how is that problem of the Planet? If the reader decides to read something, then the reader can't blame the medium for giving them the opportunity to read that. It's always up to readers to decide whether they want to read something or not. The choice is theirs already. That said, I also see no issue with occasional not-entirely-KDE-related posts on the Planet. If I'm not interested in a post, I simply scroll past it. Cheers -- Martin Klapetek
Re: Issues (Re: KDE e.V. Community Report for 2018 available)
On Fri, Nov 29, 2019 at 12:23 PM Paul Brown wrote: > On viernes, 29 de noviembre de 2019 13:39:26 (CET) Philippe Cloutier wrote: > > Le 2019-11-27 à 14:05, Aleix Pol a écrit : > > > Dear KDE community, > > > Some of you already saw it at Akademy, but we wanted to make sure that > > > you were all aware of all the great things we did last year 2018 > > > > > > https://ev.kde.org/reports/ev-2018/ > > > > Thank you Aleix and everyone involved in producing this report, which is > > more extensive than any of this kind I've seen from an open source > project. > > > > What are the proper ways to report issues in this report (or on > > ev.kde.org in general)? https://ev.kde.org/contact.php mentions "sending > > email to kde-ev-bo...@kde.org <mailto:kde-ev-bo...@kde.org>", but is it > > possible to determine if an issue was already reported there? > > If you find issues with the report (inaccuracies, spelling mistakes, > etc.), can > you post them here? This would allow several of us to solve the problems > right > away. > One suggestion for the report - it'd be awesome if the sprint group photos had names under the photo. The names are already in the text so this would just help put a face to a name. Cheers -- Martin Klapetek
Re: Facebook's KDE Connector integration app
- On Tue, Apr 9, 2019 at 5:54 PM Albert Astals Cid wrote: El dilluns, 8 d’abril de 2019, a les 17:34:14 CEST, Martin Klapetek va > escriure: > > Doesn't look like it, when I put "kde" as a username, it says it > > doesn't resolve to valid user id. If our KDE Facebook page has > > fcbid (long number), I can try that one, otherwise it's probably > > not possible. > > It's 6344818917 i think? > > At least https://www.facebook.com/profile.php?id=6344818917 redirects to > https://www.facebook.com/kde/ Nope, still says it cannot resolve that to a valid user. I think it has to be an actual user with actual email address. So, any takers? Cheers -- Martin Klapetek
Re: Facebook's KDE Connector integration app
On Sat, Apr 6, 2019 at 7:07 AM Albert Astals Cid wrote: > El dijous, 4 d’abril de 2019, a les 19:56:40 CEST, Martin Klapetek va > escriure: > > Hello! > > > > Back in the days there used to be some level of Facebook integration into > > KDE apps and a Facebook app called "KDE Connector" was used to integrate > > with it. > > > > I inherited it from the previous maintainer and it's now tied to my > > account; I keep getting alerts for this but I'm not aware of anything > using > > this Facebook app, the only occurrence I could find is a disabled > KAccounts > > provider file. > > > > As I'm no longer involved with any Facebook integration projects - would > > anyone like to take over the ownership of this Facebook app? If so > > please let me know, otherwise I'll just delete it sometime next week. > > You mention it's probably not very useful/used anymore, but maybe still > makes sense to pass ownership to the kde community user/group/page? > > Do you know if that's possible? > Doesn't look like it, when I put "kde" as a username, it says it doesn't resolve to valid user id. If our KDE Facebook page has fcbid (long number), I can try that one, otherwise it's probably not possible. Cheers -- Martin Klapetek
Facebook's KDE Connector integration app
Hello! Back in the days there used to be some level of Facebook integration into KDE apps and a Facebook app called "KDE Connector" was used to integrate with it. I inherited it from the previous maintainer and it's now tied to my account; I keep getting alerts for this but I'm not aware of anything using this Facebook app, the only occurrence I could find is a disabled KAccounts provider file. As I'm no longer involved with any Facebook integration projects - would anyone like to take over the ownership of this Facebook app? If so please let me know, otherwise I'll just delete it sometime next week. Cheers -- Martin Klapetek
Re: New maintainers wanted: KDE Telepathy, KAccounts, Plasma Notifications and others
On Mon, Mar 4, 2019 at 9:32 AM Alexander Akulich wrote: > Hi Martin and everyone. > > I would like to take over the KDE Telepathy maintainership. > > I understand that Telepathy is a huge and complex project that needs a > lot of manpower to actually come back, but there is no other project > with the same goals and capabilities. For me, Telepathy is not the > exact specification, but an idea of IM system with replaceable > components that give you a freedom to combine whatever you want across > operation systems, desktop environments, and programming languages > with the best rate of shared code and system integration. > > I can spend two hours and write a long list of reasons why Telepathy > is the right thing to do, but please let me spend this time on the > development to prove my arguments by deed and not by words. > On the other hand, I don't want to fail someone's expectations, so > please continue to not expect much. :) > > I think that in the current era of proprietary IM services, such > integrated and yet distributed solution has a chance to prove itself > with open protocols such as Matrix, Telegram (MTProto), XMPP, Tox, > Slack, IRC, SIP (reSIProcate), Gitter, Rocket.Chat, Signal, Discord > and so on. For sure the list can meet the demands of some users. > > I have interest, ideas, experience, and prototypes. Now I have some > time to start checking out features one by one. I'm already a > maintainer of TelepathyQt (I released the last three versions), but > the library and services mean nothing without a client. I have some > pending reviews for 10 months [1] and if nobody reviews them then > maybe it will be right to become a maintainer and start to land them. > > As a maintainer, I'll also take responsibility for bug fixing (as a > start I committed three bug fixes at the last three days). > > P.S.: If you're going to support Matrix then please, please! develop a > good library. I don't want to offend anyone, but QMatrixClient needs a > lot of improvements and maybe you can help. With a good library (such > as QXmpp) a Telepathy service implementation would consist of about 2k > lines of code. > > [1] https://phabricator.kde.org/D12751 Yes please! You've already proven yourself throughout the years with all your contributions, so you have my blessing :) Thanks for stepping up! Cheers -- Martin Klapetek
Re: How about an inclusive "and" approach instead of fighting IRC versus something new? (was: Re: Collecting requirements for a KDE-wide instant messaging solution)
On Thu, Aug 10, 2017 at 3:24 AM, Martin Steigerwald <mar...@lichtvoll.de> wrote: > Martin Klapetek - 09.08.17, 16:12: > > > But KDE is not a tech startup. As people correctly wrote, KDE has a > very > > > long > > > history and contributors of all age. I'd rather be that than one of the > > > many > > > tech startups with a bunch of little to no experience but fancy new > chat > > > systems, to be honest. Do we really want and need to cater these > mystical > > > tweens so much? > > > > Yes. Old contributors will slowly fade away for various > > reasons, be it life, be it lack of energy, be it other commitments. > > Who's going to pick all those projects up after them? I'd like > > to think that young enthusiasts with lots of energy and potential, > > exactly what those heroes starting the original KDE were. > > And I think we should strive to attract younger talent that can > > be in it for the long run. > > Well, I wonder since reading several posts here about one thing: > > To from reading this post and other posts I got the impression that is > absolutely needs to be black or white: > > *Either* IRC and nothing else *or* something new and nothing else. > > Seriously? > > I mean: Seriously? > > > There has been almost completely unnoticed posts mentioning bridges. Is > none > of this bridges capable to work well enough for KDE community use cases? > > Why do you see the need to exclude either one of the groups? > As you're quoting my email - where are you reading this? That's not what I wrote at. all. I merely stated that we should cater to younger engineers. Not once I suggested and will not suggest to disregard the old timers. That was twisted in replies following my email. Cheers -- Martin Klapetek
Re: Collecting requirements for a KDE-wide instant messaging solution (was: Re: radical proposal: move IRC to Rocket.Chat)
On Wed, Aug 9, 2017 at 2:51 PM, Christian Loosli <k...@fuchsnet.ch> wrote: > Okay, this is more and more drifting away from being remotely productive or > helpful, but as I provided a working solution on top level, I feel free to > tacke a few points that are, in my opinion, odd at best. > > First let's tackle that mysterious group of < 20 year olds: > > > > Is there any such organization at all? > > > > Sure there is! Look at the tech startup scene, or the games industry. > > But okay, let’s say “predominantly younger than 30” to make it an easier > > task. > > But KDE is not a tech startup. As people correctly wrote, KDE has a very > long > history and contributors of all age. I'd rather be that than one of the > many > tech startups with a bunch of little to no experience but fancy new chat > systems, to be honest. Do we really want and need to cater these mystical > tweens so much? Yes. Old contributors will slowly fade away for various reasons, be it life, be it lack of energy, be it other commitments. Who's going to pick all those projects up after them? I'd like to think that young enthusiasts with lots of energy and potential, exactly what those heroes starting the original KDE were. And I think we should strive to attract younger talent that can be in it for the long run. > Are they the holy grail that saves KDE and worth alienating > the people who are not this particular group? > It's not mutually exclusive. > Even if that is the case, to answer your question: Yes, there are such > companies, plenty even. Basically a lot of companies which are exactly not > in > the small bubble that is "tech start up", but other industries. Also > companies that actually have to do business with other companies, where > mail > simply still is the standard. > > > Then, on the subject of emojis, stickers or even the protocol used being so > important: > > Let's see what others do. Let's take our main, most famous friendly > competitor > GNOME. They even run their very own IRC network still, and actively code > new > IRC applications. > Mozilla? Own IRC network. > Reddit, quite the place for young techies and startup? Created their own > IRC > network. Hardly turning off or away people, it seems. If we fail to attract > fresh blood, then maybe the problem is not actually "we use IRC". > > But even if it would: to be honest, if someone decides what project they > want > to contribute due based on what chat protocol they use internally, I'm > personally not sure if that is a well suited candidate due to rather odd > priorities. > I think your view is a different angle - it's not that they would choose a project to contribute to based on what chat they use, but they would choose a project they feel most comfortable in. And yes day to day communication does make a big part of that comfort. No matter how you look at it, IRC /is/ behind any other IM apps/protocols today. Young engineers communicate and prefer to communicate differently than you or me. I think it's absolutely crucial to understand them and their views/ways/whatever. Neglecting them would be a mistake. Cheers -- Martin Klapetek
Re: Collecting requirements for a KDE-wide instant messaging solution (was: Re: radical proposal: move IRC to Rocket.Chat)
On Wed, Aug 9, 2017 at 2:20 PM, Thomas Pfeiffer <thomas.pfeif...@kde.org> wrote: > > > On 09 Aug 2017, at 20:00, Boudewijn Rempt <b...@valdyas.org> wrote: > > > > On Wed, 9 Aug 2017, Thomas Pfeiffer wrote: > > > >> So unless someone can give me an example of an organization younger > than 10 > >> years, with predominantly people younger than 25, > > > > Is there any such organization at all? > > > > Sure there is! Look at the tech startup scene, or the games industry. > But okay, let’s say “predominantly younger than 30” to make it an easier > task. > Can confirm. I work in a tech startup less than 10 years old with people predominantly younger than 30. We use emails internally only for announcements (max 2 per week). For everything else we use instant messaging. In fact, we have all the tooling hooked up to the IM, so even new code review or failed CI pings you on the IM. Heck, we even hooked the main door lock to the IM, so you can open doors with a simple message (has proper auth and everything). >From seeing other startups in the neighbourhood, I can tell you that all of those I've seen are like that - using whatever is the latest hip IM client because startups have to be "cool". And that raised a generation of engineers that take it for granted that orgs they'd be potentially interested in use some 21st century chat stack (but not only, GitHub is another great example). If they don't, they're automatically less interested. I agree with Thomas. If this is the kind of talent we'd like to attract, we need evolve. Cheers -- Martin Klapetek
Re: radical proposal: move IRC to Rocket.Chat
On Tue, Aug 8, 2017 at 2:51 PM, Christian Loosli <k...@fuchsnet.ch> wrote: > Am Dienstag, 8. August 2017, 20:17:08 CEST schrieb Cristian Baldi: > > Hey there, > > Hello hello, > > > [Various Issues I agree with] > > > Rocket.Chat does not have an official mobile client as of today, again > > Ruquola could solve this once it is compiled for Android. Right now the > > official way to use Rocket.Chat on mobile is to use some kind of wrapped > > WebView which does not work well (when I had that installed I did not > > receive notifications or received them randomly). > > Same goes for slack and mattermost, and these things are horrible. > First of all: they are massive battery and memory hogs. > > Same goes for the electron based wrappers that are sometimes used on the > desktop. > > Also they don't integrate UX wise. > I use Slack exclusively as the only work IM tool and none of the above is true. I'd say even the opposite. The experience on Android is pretty well integrated and overall it's a solid IM experience. Not once the battery usage showed near the top in the "apps most using battery". That's not to say "Slack's the best go for Slack", but just painting a different picture, coming from daily 10+ hours of using it. > > > As Jonathan said Rocket.Chat (but really, any modern messaging system) > > offers tons of features missing from IRC. > > Out of interest: what exactly does IRC lack? There are 4 things coming to > mind > for me, all of them with my personal opinion: > > - Lack of emojis and stickers: whilst I think it's great that I can send > stickers of kitties hugging each other on Telegram, I hardly see a need for > that in a more "professional" environment. Emojis are UTF-8 and thus > technically work on IRC and clients can handle them, if they want. > In our professional work environment, we use emojis /a lot/. Like, seriously a lot. It makes the experience that much more...human. IRC next to it feels very cold and raw, imho. Cheers -- Martin Klapetek
[kde-community] New maintainers wanted: KDE Telepathy, KAccounts, Plasma Notifications and others
Hi, as I got a new job unrelated to KDE couple months ago, I'm finding myself having less and less time and motivation to keep up with my maintainer's duties. Therefore I think it's time to pass on some of the KDE things that have my name in the "maintainer" field. First off, there's the whole notifications stack, which includes KNotifications framework, the fdo notifications server and finally Plasma's popup notifications. The whole stack is relatively simple and does not require much attention, but it could use some forward pushing to not be stuck in 2009 anymore. Staying in the Plasma land, I'd really like to hand the whole clock + calendar stack to a dedicated maintainer. This is the bottom-right part of the default Plasma panel - the clock applet, the calendar applet, the backend for these applets, calendar events, proper timezones support and all the pieces around. These things can get quite complex to grasp and improve, yet are a crucial part of the desktop experience and deserve much more attention than they get now. KAccounts, the system to set up your online accounts, could use some much needed improvements and expansions as well as integrating with the new Akonadi/Sink/Kube-thing. If the last part will not happen, and it certainly doesn't look like it will, I'm afraid that KAccounts in Plasma would no longer serve its purpose and would become a burden rather than a useful system component. The last one and the biggest one - the 12 repos of KDE Telepathy. Now this project is effectively dead. It hasn't seen any real development for more than a year and basically is just on life support ever since the core team had to leave the project because of job and life constraints. The other factor is also the wide spread of mobile phones and mobile IM clients; chatting on the desktop in not entirely modern interfaces with limited protocol support is not as popular these days. But it would still be nice to have someone at least oversee the couple of incoming patches every now and then. I think that at least the first two stacks are totally vital for Plasma desktop and really need some attention. If you'd like to put your name on any of the things above, please let me know. I'll make sure to do a proper hand-off with explaining everything :) Cheers -- Martin Klapetek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] digikam-devel moderator needed
Hey, I've been the moderator for digikam-devel for the past couple years. My time is now limited and I'd like to pass this responsibility on. Nobody from digiKam stepped up, so this is moreless just an fyi. If anybody would like to take that job, please let me know (there's about 2-10 mails everyday caught in the filter), otherwise the list is now effectively unmoderated. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Should we allow non-KDE projects to participate in GSoC under KDE?
On Fri, Feb 5, 2016 at 11:14 AM, Ingo Klöcker <kloec...@kde.org> wrote: > On Wednesday 03 February 2016 14:58:54 Martin Klapetek wrote: > > So I'd like to have this cleared - does the community agree to > > have non-KDE projects, those that do not follow the Manifesto, > > participate in our GSoC this year and in the following years? > > > > Imho this goes against the Manifesto as the projects gets to > > "enjoy the benefits" without the complying with "commitments" > > of the Manifesto. It's also less transparent overall (not able to > > monitor progress as it's not on KDE infrastructure), can lead > > to cheating and possibly kicking KDE out of GSoC in the worst > > possible outcome. > > > > On the other hand, every accepted project gets the mentoring > > organization some extra money, which is always handy. > > I'm sorry, but I completely lack the necessary information to give my > opinion > in this matter. From the thread I gather that there have been issues in the > past with at least one non-KDE project. But without a list of the pros and > cons and a short summary of the past experience with allowing non-KDE > projects > how am I supposed to decide? > If you are subscribed to kde-soc-mentor and have been in the past, look up "About GSoC mentoring" thread from 2013. In short: Tupi wanted to do GSoC with us, many people in that thread said "sorry, GSoC is only for KDE projects". That same year (and same thread) also ownCloud wanted to have a GSoC slot for better KDE integration. Again people agreed to "sorry, this is for KDE projects only" (and ownCloud didn't consider themselves a KDE project). GCompris was a similar situation but they joined in time and all was fine iirc. Year later SubSurface wanted a slot, we again said "you either become a KDE project or we're sorry" so they didn't get a slot. Last year after GSoC has started, Vishesh found out that Calamares is in our accepted GSoC projects and yet is not a KDE project (and was put up by the GSoC admin). There was a long discussion where it was said it is at least unfair to all those previously rejected projects and that it was thought to be a rule to not accept non-KDE projects based on discussions and decisions from previous years, so how come this one got accepted etc etc etc. This was all discussed on non-public mailing lists but I believe this is actually a community matter as it affects the whole community and as such the community should have a say in it. If only for the reason that we all have our little side projects that are not in KDE and would maybe want to join GSoC and nobody knows if it is allowed or not. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Should we allow non-KDE projects to participate in GSoC under KDE?
On Fri, Feb 5, 2016 at 8:42 AM, Teo Mrnjavac <t...@kde.org> wrote: > On Thursday, February 4, 2016 11:53:48 AM CET Ivan Čukić wrote: > > > Just FTR, we don't give away our own slots, but we ask for slots after > > > we decide how many projects we are going to select. > > > > And with that I'm completely fine. > > I just found myself physically shaking my head at some of the more > authoritarian-bent emails in this thread. > > In KDE we have a GSoC team that's been taking care of GSoC and other > student > programs for years now, and these people are intimately familiar with GSoC > dynamics on slot allocation and are thoroughly aware of the costs and > benefits > of allowing external projects to take part in GSoC under the KDE umbrella. > That doesn't mean you can do whatever you want though, even more so when it's a small group with no outer access. > It would be toxic to try to micromanage the Krita team, the sysadmin team > or > the WikiToLearn team: KDE has historically worked best when those who do > the > work decide how it's done. > > So here's a novel idea: how about we let the GSoC team do what they are > good > at and come up with their own policies and decisions in GSoC-related > matters? > At best, any concerns should be brought up with them on the relevant > mailing > list, rather than appointing ourselves as overseers in this thread. > I did last week and where I got told to post it here. After all it should be a community decision. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] Should we allow non-KDE projects to participate in GSoC under KDE?
Hey, so in the couple previous years we have collectively and repeatedly rejected the idea of other projects, that are not KDE projects by the Manifesto, to participate in KDE GSoC. Namely we rejected Tupi and SubSurface solely because "not a KDE project", GCompris became a KDE project and then we let it participate. Last year we got a non-KDE project in our GSoC despite the previous years decisions, nobody really noticed and then there was a huge discussion if that's ok or not, but by that time it was a bit late. So I'd like to have this cleared - does the community agree to have non-KDE projects, those that do not follow the Manifesto, participate in our GSoC this year and in the following years? Imho this goes against the Manifesto as the projects gets to "enjoy the benefits" without the complying with "commitments" of the Manifesto. It's also less transparent overall (not able to monitor progress as it's not on KDE infrastructure), can lead to cheating and possibly kicking KDE out of GSoC in the worst possible outcome. On the other hand, every accepted project gets the mentoring organization some extra money, which is always handy. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] What is a GitHub pull request exactly?
On Wed, Sep 23, 2015 at 10:36 PM, Jonathan Frederickson < silverskull...@gmail.com> wrote: > > Would it be possible to integrate Github pull requests with reviewboard? > For example, if someone submits a pull request, have a bot automatically > post it to reviewboard and post a comment on the Github side with the link. > That way, contributions through Github are accepted (without the initial > hurdle of signing up for an account), but it guides the contributor to KDE > infrastructure for discussion and review. > Follow the thread at https://mail.kde.org/pipermail/kde-community/2015q3/001892.html Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Write our own pull request bot?
On Sun, Sep 20, 2015 at 8:39 AM, Loïc Grobol <loic.gro...@gmail.com> wrote: > Granted even before that, we can see if there is enough pull request attempts to justify writing such a bot. > Gnome in their years history of github mirroring had 4 pull requests (it was mentioned in the other thread...one of the others). So we might very likely be talking non-issues here anyway. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Write our own pull request bot?
On Sun, Sep 20, 2015 at 10:59 AM, David Edmundson < da...@davidedmundson.co.uk> wrote: > > I said that number but wrt "GTK" not "Gnome" > Oops, my apologies then. Somehow I've interchanged them in my memory. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Write our own pull request bot?
On Sun, Sep 20, 2015 at 8:29 AM, Eike Hein <h...@kde.org> wrote: > On 09/20/2015 02:26 PM, Loïc Grobol wrote: > > Let's try not to be extreme. If someone was able to post a pull > > request, they should be able to switch to Phab if they want to > > participate when notified. > > Let's not be naive, either. People are lazy. That's been > one of the arguments for enabling GitHub pull requests. > People are lazy with Reviewboard too. I see no difference in that really. There are currently about 1200 (!!!) open reviews, some as old as 2011. If people want to follow the patch through, they will, if they don't they won't, no matter the toolset. Reviewboard is a nice example of that. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Write our own pull request bot?
On Sun, Sep 20, 2015 at 10:53 AM, Bhushan Shah <bhus...@gmail.com> wrote: > On Sun, Sep 20, 2015 at 8:20 PM, Martin Klapetek > <martin.klape...@gmail.com> wrote: > > > > Gnome in their years history of github mirroring had 4 pull requests > > (it was mentioned in the other thread...one of the others). > > Sorry no [1] > > https://github.com/pulls?utf8=%E2%9C%93=is%3Aopen+is%3Apr+org%3Agnome Cool. I admit I haven't checked, as I said it's a number from one of the 300 threads going on. Now we have some idea at least. <400 in a span of 3 years isn't that much still, especially for a project like Gnome. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] A bridge between Phab and Github?
On Sun, Sep 20, 2015 at 11:19 AM, Sune Vuorela <nos...@vuorela.dk> wrote: > On 2015-09-20, Emil Sedgh <emilse...@kde.org> wrote: > > What if we create a bot that makes a review request on our internal tool > > (Phab/Reviewboard) for each Github Pull request and tries to make a > > bridge between KDE's infrastructure and Github? > > > > A bot that would sync the comments/[commits/diffs] between Phab and > Github. > > I think Eike already wrote why that was a bad idea. > > /Sune > (see my other thread on that, "Write our own pull request bot?") Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Help for sprint guidance/organization
Hey, so I haven't really organized any sprints myself but have participated in many, some good, some less good. So here's my personal take on this speaking from experience: * always make everyone feel like they belong to the group and to the sprint * if it's a random group that have never met before, sometimes a short introductory round might be nice, also kind of an icebreaker * have a list of tasks for grabs and have everyone report on their progress, at least once a day, perhaps before the end of the day as well as state what their plans are, ask questions (even obvious ones, they will feel more included) * that lists of tasks can be created at the beginning with a brainstorming of "what I want to do and what I would like to see done" * coordinate often. The worst part on a sprint is if you're sitting there, unsure what to do so you just do your own thing about which nobody cares/asks * have smaller breakout sessions (when a smaller group separates and discusses some particular issues) from time to time, make other people lead those breakouts * have fun as a group - restaurants in the evening serve well, especially if you get different table setup each time (so different people talk to different people every night). This one should be treated carefully though because restaurants are not sponsored, so beware of picking an expensive restaurant and then people ending up with appetizers only cause they can't afford food. Related to that is a quick poll of "where should we eat tonight?" so that people also have a say (and again feel included in the sprint) * it's nice to have at least one night of beers and pizza out of restaurant, imho it's better socializing (and a well socialized group means better working group) * sometimes a sprint competition of some kind can be nice too, can serve as a motivation. For example who will have most closed bugs at the end of the sprint (have an up-to-date progress somewhere big and visible), just make sure that competition is not the center of the sprint, it needs to be just an additional fun (so that those not winning won't feel like failures) That's all I can think of right now, I'll add more if something comes to mind :) Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Write our own pull request bot?
On Sat, Sep 19, 2015 at 1:55 PM, Eike Hein <h...@kde.org> wrote: > On 09/19/2015 07:49 PM, Martin Klapetek wrote: > > We wouldn't get no lock-in though. Not even remotely. It will simply > > be another path for an incoming patch. If the patch in question ends > > up on Phabricator and gets reviewed on Phabricator and merged from > > Phabricator, it is no different than the patch initially arriving by > email, > > irc/paste etc. Just a different input route. > > That doesn't address Sune's concern though. If you > get a patch by email you can reply by email; the > comm channel stays the same. Ditto IRC. If you file > a pull req on GitHub and it gets imported into Phab > which you don't have an account for yet and can't > interact with using the same client (git, or the > website you were using) you were already using, you > are inserting a hump in that. The requestee wouldn't > even get emails about review comments unless the bot > does complicated steps like trying to use the GitHub > API to read out an account email (if it even can). > You'd have the email from the commit already though. The bot could be extended (over time, even) to be capable of posting comments back, even a simple "there's a new comment on your patch at ". If the user will care, s/he will care. If not, then it ends up as hundreds of already unattended patches on reviewboard, where the original submitter didn't respond to questions and/or didn't update the patch. A concrete example: https://git.reviewboard.kde.org/r/105932/ Patch from 2012 with open questions/issues from a newcomer(?), left unattended. Having the same on Phabricator with the source being github would be no different, would it? And there _will_ be patches left to rot on Phabricator anyway, just like hundreds of them right now on Reviewboard. Auto-import is a slight improvement over auto-reject > on the "it snubs people" front, but it's not a big > one and it creates a lot of practical concerns. Some > of those could be addressed with more code, if some- > one writes it - but then it should be written and > tested and evluated before we enable that channel. > Sure. It's _a_ solution. I don't claim it's a perfect one, but it is one. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Write our own pull request bot?
To further expand on the idea, the workflow would be as follows: * bot looks through our repos * bot finds a pull request * bot downloads the diff between requested branch and mirror HEAD * bot uploads it to phabricator as any other patch * bot posts message to github "Thanks for your patch, in KDE we use phabricator for reviewing and merging patches, so your pull request was posted here . If you want to follow it through, please continue the discussion at . Thanks a lot for your contribution!" * contributor follows on phabricator The problem is the needed identity account to follow it through though. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Write our own pull request bot?
On Sat, Sep 19, 2015 at 1:28 PM, Sune Vuorela <nos...@vuorela.dk> wrote: > > What happens if contributor doesn't follows? How do I as a reviewer know > why the contributor doesn't follow on? How can I reach them? > > No. let's just say no to pull requests. > Same thing as when someone emails you a patch and you reply and ask questions and never hear back. That happens quite often already. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] What is a GitHub pull request exactly?
On Sat, Sep 19, 2015 at 12:07 PM, Boudhayan Gupta <bgu...@kde.org> wrote: > On 19 September 2015 at 21:17, Martin Graesslin <mgraess...@kde.org> > wrote: > > On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote: > >> If the problem is somewhere in (a), where is it? > > > > I'm afraid of code review happening through the pull request instead of > our > > infrastructure. To me github pull requests are not just the "here's the > > patch", but also the code review. > > This. > > The other problem is that the PR submitter may not have a KDE > identity, in which case we have no way of representing the fellow and > properly crediting the commit to him/her. We have to explicitly > redirect him to KDE's infrastructure for this. > That is not true. You can credit any commit to anyone git commit --author "My Name <myem...@hello.org>" which is a standard practice around KDE, when committing patches on behalf of newcomers who don't have write access. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Renaming KScreenGenie
On Wed, Aug 26, 2015 at 10:24 AM, Boudhayan Gupta bgu...@kde.org wrote: What do you guys think about Selfie anyway? I wasn't able to find any app that was called Selfie, and after the initial cringe, I gave it some thought and my two cents - I like the edgy, err, youthful, totally non-enterprise, couldn't give two hoots about corporate branding vibe that this gives off. And of course, I couldn't say this enough times, a screenshot is a computer taking a selfie. But then selfies are what keeps the current teen generation going. The easy confusion with a software that takes an actual selife (the user taking it, ie. his own) is at hand. Software names should not be confusing. Besides, thanks to the word getting into pop-culture main-stream English nowadays, it's as generic as Screenshot is ;) Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Renaming KScreenGenie
On Mon, Aug 24, 2015 at 9:24 AM, Boudhayan Gupta bgu...@kde.org wrote: On 24 August 2015 at 18:45, Martin Klapetek martin.klape...@gmail.com wrote: KSnapshot2. One of the points brought up was that KDE Applications are moving away from using a K-prefixed name, so I want to ride that bandwagon. My other suggestion would then be Snapshot. Keeps it simple and recognizable, kinda tied to KSnapshot even, no need for the fancy/cryptic names, I'd say. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Make the World a Better Place! - KDE End of Year 2014 Fundraising
On Wed, Oct 22, 2014 at 10:56 PM, Thomas Pfeiffer thomas.pfeif...@kde.org wrote: On Wednesday 22 October 2014 21:36:41 Dominik Haumann wrote: today came the thought to me that we also could send this mail to all users that once wrote a comment in http://bugs.kde.org. There, we have lots (how many) of users that at least were in touch with KDE through the bug tracker, and since quite a lot of bugs do get fixed, quite a lot of these users might even be happy users and willing to donate to KDE :-) What do you think about this? Maybe we could reach thousands of KDE users this way? Hm, this does _sound_ nice, but I don't see it as ethical and it may even get us into legal trouble. When registering with BKO, users did no give their consent to receiving emails about anything other than bugs. If we now send them emails asking them for donations, at least some will likely get quite angry. If we want to do something like that in the future, we have to give to give users an opportunity to opt in for other messages from KDE when registering for BKO (or when filing a bug). Only spammers send unsolicited emails. We are not spammers. It could be just part of the message Bugzilla sends, like in the footer. Simple Make the world better - link. Bugzilla mails always have at least 2 lines footer anyway, like You are receiving this mail because: You are on the CC list for the bug. Could work. 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
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] Berlin - Brno road trip
On Thu, Aug 21, 2014 at 8:36 PM, Thomas Baumgart t...@net-bembel.de wrote: Don't EC trains have *some* power outlets? If there's enough thinkpads, we can share one outlet across multiple machines They do, last time I tried one of them it only had limited power not even enough to drive my notebook alone. I hope you don't run into the same problem but don't be surprised if you do. Fwiw, I traveled the route Prague-Berlin and back lots of times (last time one year ago) and the trains never had power plugs. But maybe things changed now, dunno :) Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Berlin - Brno road trip
On Wed, Jun 18, 2014 at 12:06 PM, Milian Wolff m...@milianw.de wrote: Sounds good. I have a Bahncard 25. What about the way back though? Isn't it cheaper to book both directions in one go? If so, maybe all of us should just book this on our own? Or is there a group rebate? For anyone interested, on the Czech railways, you do have a group rebate and the total price is calculated as follows: - 1st traveler pays the whole price - 2nd traveler pays 75% of what the first one paid - 3rd and any others pay 50% of what the first paid So for example if Prague - Brno costs 210 CZK for one, it will be 368 CZK for two, 473 CZK for three, 578 CZK for four people etc. Might be handy for people going via Prague :) Oh and there's this great site for looking up connections in and around Czech republic including public cities transport - http://idos.cz - can do multilingual too. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Berlin - Brno road trip
On Wed, Jun 18, 2014 at 4:47 PM, Laszlo Papp lp...@kde.org wrote: This is great, but would it be possible to record this on the akademy traveling page? http://akademy.kde.org/2014/travel-brno I guess, but I don't have the rights to edit that. Dan? On Wed, Jun 18, 2014 at 11:31 AM, Martin Klapetek martin.klape...@gmail.com wrote: On Wed, Jun 18, 2014 at 12:06 PM, Milian Wolff m...@milianw.de wrote: Sounds good. I have a Bahncard 25. What about the way back though? Isn't it cheaper to book both directions in one go? If so, maybe all of us should just book this on our own? Or is there a group rebate? For anyone interested, on the Czech railways, you do have a group rebate and the total price is calculated as follows: - 1st traveler pays the whole price - 2nd traveler pays 75% of what the first one paid - 3rd and any others pay 50% of what the first paid So for example if Prague - Brno costs 210 CZK for one, it will be 368 CZK for two, 473 CZK for three, 578 CZK for four people etc. Might be handy for people going via Prague :) Oh and there's this great site for looking up connections in and around Czech republic including public cities transport - http://idos.cz - can do multilingual too. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Sat, May 3, 2014 at 2:19 PM, Myriam Schweingruber myr...@kde.org wrote: Very simple: we try to get our releases out for the users and try to get into major distributions (not rolling ones), not for our own schedule's sake. And fixed release cycles are one thing, but the availability of the devs to push and polish their work is another one. Also: doing our own release in Amarok might look like more work, but we reach a greater audience than if we would stick into a KDE releases x.y.z and get a one liner mention in an endless list nobody ever reads anyway. When did anybody here read the full release text of the KDE SC releases, but those who wrote them? The longer it gets, the less likely anybody would read it, don't forget the tl::dr attitude of most people I fear we are again doing a lot of blabla but nobody thinks about the users perspective as usual. I understand if kdelibs devs or Solid or whatever underlying structure they work on don't think of users as their first target, but that is certainly not so for applications like Amarok. So if everybody would take a step back and think of to whom and where and how we want to achieve a better distribution, then strict release schedules, regardless of the actual length, are not really helpful, they are a constraint to people who work in their free time and we try to apply company rules to them. That just doesn't work. Alienating the non-rolling distributions by our new schedules doesn't help either, btw. With my KDE Telepathy hat on (as a main co-maintainer and the dude that does every other release), I'm putting +1 to that. I keep seeing that the joint release would be simpler, but to whom? The release people (doing the packages) would suddenly have bazillion new packages to do (just KTp has ~14 and it varies). I kinda don't want to hand our release job to someone else as it's a bit specific process and afaik it's not the same as the rest of KDE apps, so handing this over would actually put *more* complexity onto the release team as suddenly they would have to handle lots of apps with different release processes. As for being simpler for promo - well, maybe. But the promo team would ask us hey, can you give us some text about your release and we would have to write one, but we do so now as well, except we can do bigger posts. Plus, we would get lost in the endless list, like Myriam said. We actually used to align our release with KDE SC but then decided to have some offset as our impact to the users and media was far less than when released standalone. True story. I'm not sure if it would be simpler for translators either - sure, there would be a global string freeze every month the same day, but it seems to me like lots of work suddenly cumulates at once. But this is just my thinking and I'm no translator. Well I don't know, I don't want to be the nay-sayer, but these are my thoughts on that. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Wed, Apr 30, 2014 at 10:48 AM, Jos Poortvliet jospoortvl...@gmail.comwrote:
On Monday 28 April 2014 11:08:34 Martin Klapetek wrote:
On Fri, Apr 25, 2014 at 10:12 PM, Jos Poortvliet
jospoortvlietstanburd...@gmail.com jospoortvl...@gmail.com wrote:
I think the idea of grouping releases ('Sigma'?) is a good one. How
about
we
start there. Let's give Applications more freedom, yet allow them to be
part
of the 'bunch', yes? Calligra, Amarok, the Extragear apps - they should
be
part of the KDE Applications. Fold it all in there, with more
flexibility
thanks to more regular (but non-mandatory) releases. Yes, everybody
their
own
release numbers, no synchronization needed at all. Not every release
needs
every application, but perhaps for convenience of distro's we provide
everything in a tarball- just not with updated version numbers. They
can
ship
KDE Applications 2015.6 (?) and be sure to have all of them, but many
of
the
apps might not be different from those in KDE Applications 2015.2.
I think the release numbers should be all the same and perhaps even the
number of the Sigma release (also, we should come up with something
else
than Sigma before it catches on and stays...like SC...unless we want
it
to stay). Otherwise it will be a mess imho - KDE Applications 2015.6
contains Dolphin 5.2.1, Calligra 7.8, Amarok 4.6.4, Kontact 5.3.1 --
KDE
Applications 2015.12 contains Dolphin 5.2.3, Calligra 8.1, Amarok 4.8.2,
Kontact 5.4.1are those own version numbers really that important? It
could just as well be Dolphin 2015.6 or Amarok 2015.12 (or some other
numbers), but unified. More coherent, more clear, more simple. The
downside I see is that the apps' developers would need to commit to this
new policy, which might hit some resistance.
Look at what we try to do here: message that our applications are separate
and independent. There is nothing about Ktouch that requires Amarok, and
Words is just fine without Kanagram. The fact that, on a release
engineering
level, we release them in batches - that is irrelevant for users. They just
get the one app they want, be it for Windows, Mac, Linux, Android...
Delivering it as a 'suite' with the same version numbers gives the
impression
they do belong together. But they don't - the only thing KDE software has
in
common is the people who make it. Functionally, you can use them anywhere,
alone or in groups, separate or combined.
From the original proposal I understood the core apps would actually
belong together, to form the core. Is that not the case?
Also - most apps wouldn't release with every sigma release, so more than
half
our applications is out of sync most of the time. Having Kontact and
Gwenview
2014.8 and Words and Palapeli 2014.6 and Amarok 2015.2 all being the latest
version seems more confusing than Kontact 1.8, Gwenview 2.3 etc etc on
their
own. That is what people are used too.
I don't see a strong argument for syncing the release numbers, the
confusing
part doesn't convince me. There's plenty of different version numbers on
your
system atm ;-)
But if anybody knows a good reason to sync, say so please.
To be honest I don't see the point of my application actually joining the
joint release...
And then we have Plasma, as it is now - the core desktop
(netbook/media
center) experience. Kwalletmanager, Systemsettings - they are part of
this
already, aren't they? That makes sense. The criteria: you really need
them
to
use Plasma Desktop in a reasonable way (eg 95% usecase).
To satisfy the need of distributions (and users) to know what they
should
have
for a basic, functioning, KDE-software based desktop, we define the KDE
Essentials. Very bare: Konsole, Kwrite, Dolphin, Ark, Okular, Gwenview,
you can imagine. The criteria: EVERY user (well, ~90%) uses these
applications, BUT you can swap them with another without everything
falling apart.
I'm a bit skeptic about the metric here. I'd rather maybe define sets of
goals the user should be able to do with our desktop and then make the
list
from that - the user must be able to read a PDF; the user must be able
to
view pictures etc.
Well, sure, but what criteria do you use to decide what criteria should be
part of the core set?
Common sense and usability knowledge :) We should simply decide what our
desktop should do and not do based on our intended target users. More below.
A DTP app won't be part of core following what I
propose, but The user must be able to do DTP seems a perfect fit to the
user should be able to do X list.
In other words, I'd argue that the user must be able to do X is a
criteria
that follows out of defining what 95% of the users use. It doesn't work on
its own.
You cannot define what 95% users use because you don't have that data. We
don't know our users. We don't even know how many there are, let
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Fri, Apr 25, 2014 at 10:12 PM, Jos Poortvliet
jospoortvlietstanburd...@gmail.com jospoortvl...@gmail.com wrote:
I think the idea of grouping releases ('Sigma'?) is a good one. How about
we
start there. Let's give Applications more freedom, yet allow them to be
part
of the 'bunch', yes? Calligra, Amarok, the Extragear apps - they should be
part of the KDE Applications. Fold it all in there, with more flexibility
thanks to more regular (but non-mandatory) releases. Yes, everybody their
own
release numbers, no synchronization needed at all. Not every release needs
every application, but perhaps for convenience of distro's we provide
everything in a tarball- just not with updated version numbers. They can
ship
KDE Applications 2015.6 (?) and be sure to have all of them, but many of
the
apps might not be different from those in KDE Applications 2015.2.
I think the release numbers should be all the same and perhaps even the
number of the Sigma release (also, we should come up with something else
than Sigma before it catches on and stays...like SC...unless we want it
to stay). Otherwise it will be a mess imho - KDE Applications 2015.6
contains Dolphin 5.2.1, Calligra 7.8, Amarok 4.6.4, Kontact 5.3.1 -- KDE
Applications 2015.12 contains Dolphin 5.2.3, Calligra 8.1, Amarok 4.8.2,
Kontact 5.4.1are those own version numbers really that important? It
could just as well be Dolphin 2015.6 or Amarok 2015.12 (or some other
numbers), but unified. More coherent, more clear, more simple. The downside
I see is that the apps' developers would need to commit to this new policy,
which might hit some resistance.
And then we have Plasma, as it is now - the core desktop (netbook/media
center) experience. Kwalletmanager, Systemsettings - they are part of this
already, aren't they? That makes sense. The criteria: you really need them
to
use Plasma Desktop in a reasonable way (eg 95% usecase).
To satisfy the need of distributions (and users) to know what they should
have
for a basic, functioning, KDE-software based desktop, we define the KDE
Essentials. Very bare: Konsole, Kwrite, Dolphin, Ark, Okular, Gwenview, you
can imagine. The criteria: EVERY user (well, ~90%) uses these applications,
BUT you can swap them with another without everything falling apart.
I'm a bit skeptic about the metric here. I'd rather maybe define sets of
goals the user should be able to do with our desktop and then make the list
from that - the user must be able to read a PDF; the user must be able to
view pictures etc.
Example: You can't configure things without Systemsettings (gnome
systemsettings won't do the trick for you...), you can't save passwords
without kwalletmanager, but you can replace Dolphin with Nautilus and Kate
is
most likely not needed by ~90% of our users. So Systemsettings goes in
Plasma,
Dolphin in Essentials, Kate in its module in KDE Applications.
Accessibility
also probably belongs in Essentials, not for 90% of the users needing it
but,
well, let's call it human decency that accessibility is something we
consider
essential!
We ship no duplicates in the essentials, and have a best-of-breed policy.
Let
the release managers decide what goes in, in consensus-style discussion
with
the application maintainers, that should generally work just fine. The
modules
- I think they can stay where they make sense for their respective teams
(KDE
Edu comes to mind) and just go away where they already don't really exist
(KDE
Admin) or make no sense.
+1
Cheers
--
Martin Klapetek | KDE Developer
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
