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 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 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 wrote: > > > On 09 Aug 2017, at 20:00, Boudewijn Rempt 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 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
Re: Martin k and olaf win akademy award
On Sun, Jul 23, 2017 at 1:10 PM, Jonathan Riddell wrote: > Martin k and olaf won an akademy award for many years hard work on KDE > free qt foundation *Martin Konold (I assume), just to disperse the ambiguity :) 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 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 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] ktp-accounts-kcm
On Thu, Nov 26, 2015 at 12:28 PM, Alihan ÖZTÜRK wrote: > http://www.sudrap.org/paste/text/655652/ > > KAccountsMacros error. > Install kaccounts-integration. 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 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] A bridge between Phab and Github?
On Sun, Sep 20, 2015 at 11:19 AM, Sune Vuorela wrote: > On 2015-09-20, Emil Sedgh 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] Write our own pull request bot?
On Sun, Sep 20, 2015 at 10:53 AM, Bhushan Shah wrote: > On Sun, Sep 20, 2015 at 8:20 PM, Martin Klapetek > 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&q=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] Write our own pull request bot?
On Sun, Sep 20, 2015 at 8:29 AM, Eike Hein 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 8:39 AM, Loïc Grobol 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] 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 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?
On Sat, Sep 19, 2015 at 1:42 PM, Laszlo Papp wrote: > > Sure, but why would increase this situation further on? > Sorry, I don't understand this question. > I agree with everything that Sune wrote. Reaching them might be > particularly important when changing license just for one of those. > There could be numerous other valid examples. > > Why put energy into making sure that they can diverge from the normal > workflow rather than putting energy on making sure that the workflow > is known and easy to get? > To get the best of both worlds. > There used to be life before github, too. This is exactly the vendor > lock-in, when some people can no longer breat without it for such > simple things. > 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. 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 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] 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
[kde-community] Write our own pull request bot?
Look, if the problem of github pull requests is the concern of KDE reviews eventually moving there (and create pressure on others etc), why don't we all throw one afternoon of our time and write a bot that will automatically import the pull request as a patch into phabricator? That way, creating a pull request on github would get automatically imported on phabricator where we all could a) review it b) merge it without actually moving to github, but simply utilizing its resources. Seems like a win-win? We could even base it on that bot that is automatically closing those pull requests that was linked twice already. The only limitation I see is the needed Identity account for submitting patches on phabricator (right?), but other than that, how hard can it be(tm)? 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 wrote: > On 19 September 2015 at 21:17, Martin Graesslin > 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 " 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 Fri, Sep 18, 2015 at 2:47 PM, Boudhayan Gupta wrote: > > While it is a bit late now (the repository rename was done yesterday), > I'm still in love with the word Selfie (for the above reasons and > more). I'm heavily considering requesting another rename to Selfie. > > Are there any strong objections? > I for one really don't like it. 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 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 wrote: > On 24 August 2015 at 18:45, Martin Klapetek > 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] Renaming KScreenGenie
KSnapshot2. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] stackexange site for krita
Anyone btw. knows how the Ubuntu instance at askubuntu.com fits in? I wonder if it is hosted by Canonical or just by SE Inc. and running on its own domain...and if Ubuntu people got more power in the moderation and 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] Make the World a Better Place! - KDE End of Year 2014 Fundraising
On Wed, Oct 22, 2014 at 10:56 PM, Thomas Pfeiffer 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 1:09 PM, Mario Fux wrote: > 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. > Precisely. The "kde-devel is the mailing list where technical/software development in the KDE community happens" is how I feel and why I think there should be a support mailing list for people *outside* the KDE community. 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, something like frameworks-supp...@kde.org. If anything, it at least servers marketing purposes ;) Btw. looking at kde-devel archives for the month July, I counted 4 non-inside-KDE related emails out of 166 (of which most are review requests but that was talked through before). 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 12:16 PM, Aaron J. Seigo wrote: (not responding to the rest as that's no use) > Using and developing are two separate things; frameworks-devel is about the > latter > > For using KDE technology in development, you have aptly described the > purpose > of kde-devel@ > > Perhaps the real question you are asking is: How do we get people to know > about Frameworks and then sent to the right mailing lists? > > It is apparently your contention that people will go to > http://lists.kde.org/ > and guess which list to use or generate a possible email address on their > own > (and perhaps search for it on the internet before using it). That is > probably > quite unrealistic. > > A proper website for KDE Frameworks that presents it as a product proper > would > be a far more useful and compelling asset for getting people to KDE > Frameworks, and that website can point to whatever mailing lists it > chooses. > Google will with near certainty then point to those lists when someone > searches for "kde frameworks mailing list". > > 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? 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 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 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 4:47 PM, Laszlo Papp 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 wrote: > On Wed, Jun 18, 2014 at 12:06 PM, Milian Wolff 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 12:06 PM, Milian Wolff 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
I'm putting this reply separately as it's not directly related to the previous one... On Sat, May 3, 2014 at 2:19 PM, Myriam Schweingruber wrote: > > Also: changing names all the time and making releases for "KDE sc and > x and y and z and plasma and don't call it KDE" are just not working, > did ever anybody of you got aware that the whole rebranding to "KDE is > not what we release, it's a community" is a complete and utter > failure? I stopped long ago correcting people who call what they get > on their desktop "KDE" and not "KDE SC with plasma desktop" or > whatever is the "official" name we should use. It just doesn't work. > Period. > I think we have a great chance now, to start fresh with the upcoming release. But we have to get it right and we don't have much time left. > So let's get the perspective right: people want KDE, and there are > already tons of posts out there in the web where people don't call it > Frameworks5 but KDE5, and not even KDE devs commenting on those posts > correct that anymore. Make a search and you will get aware of the > reality, stop pretending it didn't happen. > The current situation is less than fortunate, indeed. But it's not that bad I think. There is a general knowledge in the world what Frameworks are (although I see it called "KDE Framework" a lot as one single framework is more common in IT world; Qt is a framework too after all (no trailing s)), the rest is a bit blurry, so people just go "KDE5" as it's simple and everybody understands what is meant by that. My idea, which might be a complete nonsense, is to figure out the new overall branding for our software, keep it all simple, drop the technical accuracy (users don't care about technical stuff...so many times we have said that and then we have put it right into our main brand names) and be bold about it. No hiding it in the release text, make it big, clear and bold - "The software is no longer KDE, we're now". And make it big promo. It can never succeed if it will be just one or two sentences in the release text. People need to get slapped in the face with it for it to have any effect. Twice. 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 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 wrote:
> 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 > 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.1"are 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
Re: [kde-community] Proposal One: KDE (Core) Apps and Suites
On Fri, Apr 25, 2014 at 10:12 PM, Jos Poortvliet <
jospoortvlietstanburd...@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.1"are 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
Re: [kde-community] Future Git Plans
On Tue, Feb 18, 2014 at 5:19 PM, Jeff Mitchell wrote: > On 18 Feb 2014, at 8:02, Martin Klapetek wrote: > >> Fwiw, the Review Board guys are working on a push-based review system, >> bascially a gerrit with RB interface. This is a set of extension scripts >> usable with RB 2.0, which brings many other features as well, you can >> watch >> a video of it here: http://vimeo.com/86448355. Also, we can even wire our >> own "Push" button into RB, it's quite simple from what I understood and >> could merge patches for us without needing to do "git push" ourselves >> everytime. >> > > Generally speaking, Gerrit needs to "own" repositories. Would this require > some sort of thing like RB hosting the Git repos? Sort of, it would need its own clone of the repos, which is moreless the case right now anyway right? But I imagine it brings all sorts of synchronization issues with it... Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Future Git Plans
On Tue, Feb 18, 2014 at 1:45 PM, Frederik Gladhorn wrote: > > > I tried working with github for a project, using a workflow of reviewing > each commit. I personally really disliked it for creating a merge commit > for each commit, that just clutters up the history (try looking at any > github project with a few contributors). > > > > Is this the same with gitlabs or can it cherry-pick after successful > reviews? > > > > On the other hand I find dealing with reviewboard quite cumbersome and > thus this option still looks better to me. > Fwiw, the Review Board guys are working on a push-based review system, bascially a gerrit with RB interface. This is a set of extension scripts usable with RB 2.0, which brings many other features as well, you can watch a video of it here: http://vimeo.com/86448355. Also, we can even wire our own "Push" button into RB, it's quite simple from what I understood and could merge patches for us without needing to do "git push" ourselves everytime. I would personally very much prefer to stay with RB if possible, plus the devs are really awesome and helpful. Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
On Mon, Jan 20, 2014 at 6:29 PM, Martin Sandsmark wrote: > > The obvious downsides things being replaced would suffer from, thanks to > the > immature state of the desktop components, and not including the previously > mentioned obviously broken components; dreadful performance, no proper > accelerator management, no form layouts, and poor QStyle support (both > Oxygen > and QtCurve has worked around some of them now, though, but I doubt it will > be good for a long, long while). > Just for the record, we now have almost 1-to-1 visual consistency of QtQuickControls with Oxygen style and classic QWidgets with Oxygen style. Couple patches are still pending. The QStyle support in QQC may be a bit hack~ish, but I wouldn't say exactly poor - in fact, all the default Qt styles work fine with QQC (that includes Windows and OS X QStyles). Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
