Re: Croutons in kdereview
Hello, I don't think Jonah's question got an answer. If it did somehow it didn't show up in my mail client and my apologies in advance. :-) In any case I've been wondering exactly the same thing. I'm asking because the fate of libraries like QCoro and Croutons would be to end up in KDE Frameworks at some point (at least would make sense to me). It'd be odd to have two overlapping libraries like this. Regards. On Monday, 30 August 2021 13:10:35 CEST Jonah Brüchert wrote: > Hi Janet, > > I know I have asked this earlier already, but what is the relationship > between your library and QCoro? > > Especially now that we are starting to use QCoro in some KDE projects > (namely spacebar and plasma-dialer), it would be really unfortunate if > they are not compatible. > > The scope of both libraries seems to largely overlap, except for the > future type that can be passed to JavaScript, which I think is something > that QCoro is missing. > > > I hope this hasn't been asked already on this list, but I tried to check > all replies I could find. > > > Thanks, > > Jonah > > Am 29.08.21 um 05:10 schrieb Janet Blackquill: > > Hello, > > > > https://invent.kde.org/libraries/croutons is in kdereview now > > > > Croutons is a library containing assorted functionality for dealing > > with asynchronous code in Qt, most notably a future type that can be > > passed into QML as a JavaScript Thennable (similarly to Qt IVI's > > PendingReply) and headers for C++20 coroutine integration for the > > Croutons Future types + some Qt types that make sense to co_await. > > > > The library is largely headers-only, sans the FutureBase, which has > > one (1) associated source file needing to be compiled into a binary. > > > > -- Janet -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: Koko in KDEReview
Hello, Disclaimer: likely a super useless email. On Wednesday, 5 May 2021 15:23:11 CEST Nate Graham wrote: > On 5/5/21 6:41 AM, Harald Sitter wrote: > > On 04.05.21 17:53, Carl Schwan wrote: > > Side note: this isn't a special need TBH ;) > > Pretty much everyone has that need. So much so that I kind of have a > > general game plan that there ought to be a kbugreport utility which is > > able to gobble up all the very specific data $product needs through > > scripts or something and either attaches the data to an existing report > > or files a new one. Cause a filing template also only gets you so far + > > for the causal user it's still a fairly meh experience. > > I am super duper in favor of this and I think it's a great idea. VDG has > some mockups for a desktop bug filing app, in fact. We'd love to share > them with you if you pop by in the chatroom (#kde-vdg). A long time ago in a gal... well... a long time ago, we had something called KBugBuster. Was probably a bit too much bugzilla and triaging focused. Looks like it completely disappeared though, didn't find trace of its code. Cheers. PS: I warned you. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: KF6 online sprint: March 27-28
Hello, On Wednesday, 24 March 2021 14:11:19 CET David Edmundson wrote: > I wanted to bump this thread, just so people remember that it is this > weekend! There are many many slots still available. Well, in our great tradition, my expectation is that the first hour will be devoted to filling the other slots. ;-) Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: KCGroups in KDEreview
Hello, On Tuesday, 2 March 2021 12:06:51 CET David Edmundson wrote: > > > (where 1000 is of course dynamic) > > > > Ditto, what enum names could we give to those? > > / -> All > /system.slice -> System > user.slice/user-1000.slice/user@1000.service -> User > user.slice/user-1000.slice/user@1000.service/app.slice -> UserApps > user.slice/user-1000.slice/user@1000.service/session.slice -> UserSession > user.slice/user-1000.slice/user@1000.service/background.slice -> > UserBackground Sounds good to me. Let's go for this. Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks 6 - Virtual Sprint setup
Hello, On Saturday, 30 January 2021 12:14:27 CET Volker Krause wrote: > Thanks for driving this, I'm in! European hours preferred, any weekend > starting from w6 should be possible. Same here, not before week 10 or even better not before week 13. Cheers. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: KCGroups in KDEreview
On Sunday, 13 December 2020 22:41:24 CET David Edmundson wrote: > On Thu, Dec 3, 2020 at 11:48 AM Kevin Ottens wrote: > > Hello, > > > > On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote: > > > Ultimately this isn't really dealing with cgroups directly but with > > > the manager to control them, systemd. > > > > > > That's correct usage, kernel docs of cgroups say to go via a > > > controller for write operations. However that at point is it worth > > > naming the library ksystemd? > > > It might cause some contention due to people who get angsty at a name, > > > but it's a lot more fitting. It would then give us a place to dump a > > > lot of other wrappers (especially logind) that we're seeing duplicated > > > in a bunch of places throughout KDE. > > > > Aren't you concerned this might lead to one of our infamous dumping > > grounds? > > > > There's always a tension between making it too focused and tiny or > > unfocused and with blackhole mass... we'd need to find where it stands > > but "systemd wrappers" looks too loosely defined to me. > > > > > > Do we have a list of the wrappers you got in mind and which piece of > > feature they all provide? > > StartUnit, given this has a StopUnit > Used by plasma-workspace and plasma-firewall > > Logind I have wrappers in: > - kwin > - libkworkspace > - SDDM > - powerdevil > - kscreenlocker > > None wrapping all of it, only what they need, but there's still overlap. > You're right that could be a separate framework if that's preferred. I'll be honest I'm still unsure what that'd mean in practice... What about drafting API for a couple of those? Let's not get overboard implementing stuff and so on, it's more exploratory that anything for now. > > > I think we've artificially limited the usage of the library. > > > The code is very generic for handling units, but all the names and one > > > tiny line limit it to only managing a subset of units. > > > > > > If we make the "glob" static used in KApplicationScopeLister's have a > > > public setter (or a protected virtual) we can rename this class and it > > > becomes a much more generic library for others to use outside of any > > > initial use-case. > > > > Good point. Got a similar question though, which other unit types would be > > useful to control? Reason being that API wise I'd smell an enum for > > something like this. > > Enum potentially works too. > > Describing things in terms of cgroup hierarchy, I think the key use cases > are: > > / > user.slice/user-1000.slice/user@1000.service > user.slice/user-1000.slice/user@1000.service/app.slice > user.slice/user-1000.slice/user@1000.service/session.slice > user.slice/user-1000.slice/user@1000.service/background.slice > (where 1000 is of course dynamic) Ditto, what enum names could we give to those? Yes, I know I roll with questions. :-) Cheers. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: KCGroups in KDEreview
Hello, On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote: > Ultimately this isn't really dealing with cgroups directly but with > the manager to control them, systemd. > > That's correct usage, kernel docs of cgroups say to go via a > controller for write operations. However that at point is it worth > naming the library ksystemd? > It might cause some contention due to people who get angsty at a name, > but it's a lot more fitting. It would then give us a place to dump a > lot of other wrappers (especially logind) that we're seeing duplicated > in a bunch of places throughout KDE. Aren't you concerned this might lead to one of our infamous dumping grounds? There's always a tension between making it too focused and tiny or unfocused and with blackhole mass... we'd need to find where it stands but "systemd wrappers" looks too loosely defined to me. Do we have a list of the wrappers you got in mind and which piece of feature they all provide? > I think we've artificially limited the usage of the library. > The code is very generic for handling units, but all the names and one > tiny line limit it to only managing a subset of units. > > If we make the "glob" static used in KApplicationScopeLister's have a > public setter (or a protected virtual) we can rename this class and it > becomes a much more generic library for others to use outside of any > initial use-case. Good point. Got a similar question though, which other unit types would be useful to control? Reason being that API wise I'd smell an enum for something like this. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: KCGroups in KDEreview
Hello, On Friday, 20 November 2020 14:55:16 CET Henri Chain wrote: > KCgroups has been moved to KDEReview ! > What is that, you ask ? It's a library that wraps the systemd dbus API to > expose a higher-level concept of desktop application and allow control of > its system resource usage (CPU, RAM, IO, etc). > > It relies on the recent ability of plasma to launch applications in their > own systemd scopes, with correspond to cgroups and provides a more robust > definition for an application (more details at > https://lwn.net/Articles/834329/ ) . > > The main use of the library is to expose related resource control settings > for those applications, at a user space level that other KDE applications > and frameworks can use, including consumption straight from QML as > demonstrated in the test application. > > KCgroups is intended to become a (Tier 1) framework. A first user of this > library might be the foreground window CPU booster daemon that is available > here: > https://invent.kde.org/libraries/kcgroups/-/tree/work/foreground-booster > > Packages are already available for both Neon and Arch Linux. > > Looking forward to your feedback and ideas for using this, Glad to see this come to fruition. One concern regarding use with other libraries: * the OPTIONAL_GADGET use introduce names that I could see potentially clashing with application code or code in third party libraries, I wonder if they should be moved in a namespace as well (as in "like optional") or have a K name at least; Minor things I found: * tests/main.cpp needs to have some of its includes cleaned up (at a glance QDebug and QTimer aren't needed there); * tests/main.qml should have better ids for its elements IMHO, often those manual tests end up used as examples by people and having better readability helps (also avoids having people copying and pasting shameful things). ;-) That's not much but I'm obviously biased by the fact that we discussed this API together already. :-) Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: Kup in KDE Review
Hello, On Thursday, 9 April 2020 07:25:34 CEST Simon Persson wrote: > On 2020-04-07 06:01, Nicolas Fella wrote: > > I briefly skimmed trough the codebase. Looks all sane to me. A few > > minor observations: > > > > - You may want to look into KConfigXT. It should be able to generate > > the classes from settings/ from an XML description. > > I think that I looked at it when I started Kup, about 10 years ago... > don't remember exactly but I think the issue was about dynamic > configuration entries. Kup allows user to create as many backup plans as > they want and each will have some settings. By the sound of it you might want to look into parameterized groups: https://api.kde.org/frameworks/kconfig/html/kconfig_compiler.html This feature has been there forever but is often overlooked. Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: Possible to move some KF5 frameworks to invent?
Hello, On Monday, 12 August 2019 13:48:46 CEST David Faure wrote: > In any case, we should be able to make a list of stable branches, > especially if we can use wildcards like Applications/*. And that's kind of the way GitLab works IIUC. By default only master is protected, but you can set extra rules based on such a wildcards scheme. Beside, this would put some order to that naming going forward, I see that as a bonus. Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: Possible to move some KF5 frameworks to invent?
Hello, On Sunday, 11 August 2019 22:14:19 CEST Albert Astals Cid wrote: > With phabricator you can do a "force push" to your review[1], with gitlab > you can not[2]. > [...] > [2] without having your own fork of a repository, that is annoying for > various reasons I'm genuinely surprised about that claim. Are we sure that it's not a setting on our instance forcing this? I'm currently working on a project where you can force push in non-protected branches without your own fork. Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: kaudiocreator to unmaintained
Hello, On Friday, 24 May 2019 17:10:20 CEST Bernd Steinhauser wrote: > Did you guys have a look at audex? I didn't know about this one indeed. > Last time I looked at both audex and kaudiocreator, I found the former to be > in a much better state. That's also why I put in some effort to port it to > kf5 (at the time neither of the two was ported). > > Right now the main issue with audex is that the cover fetching doesn't work > (since Google removed a related API), but apart from that it works very > well. > > Of course, if you – for whatever reason – prefer kaudiocreator, feel free to > continue with that one. > Just wanted to point out that audex exists as well. ;) Thanks for bringing it up. I had a bit of time to look into it, and it looks like audex is in a better state and it has seen some activity from Heiko in the last few months which kind of de facto makes him maintainer. ;-) Since I'd rather we have one project with a team size > 1 that two with a team size of 1, I'll retract my previous offer of reviving kaudiocreator and turn my attention to audex instead. Hopefully we can get it out of playground and into KDE Applications. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: kaudiocreator to unmaintained
Hello, On Tuesday, 21 May 2019 22:16:10 CEST Albert Astals Cid wrote: > I don't want to block on this, but given it seems relatively likely the > "community" would be doing maintaince on this if it joins KDE Applications, > I'd really welcome if this wouldn't depend on kdelibs4support. > > Has anyone attempted to port away from it? Not yet, but definitely something I want to tackle soon-ish. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: kaudiocreator to unmaintained
Hello, On Monday, 20 May 2019 01:10:27 CEST Jonathan Riddell wrote: > Do you plan to push this commit. Just done now. > Will you make releases? I'd like it to be part of KDE Applications. Unlike Zanshin I'd rather have this one tied to the Applications release cycle. That being said, it's been eons since I had anything in the regular applications collection. Could someone refresh me on what it entails to "make release"? Back in the day it was fairly transparent, if that's still so low on work I can easily say yes... if not I'll have to evaluate. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: kaudiocreator to unmaintained
Hello, On Tuesday, 14 May 2019 17:39:30 CEST Luigi Toscano wrote: > On Tuesday, 14 May 2019 16:44:43 CEST Jonathan Riddell wrote: > > I'd like to propose moving kaudiocreator to unmaintained > > > > No commits since Mar 8 22:11:33 2017 > > > > No releases in KF5 time > > > > Obsolete technology > > Copying also the last maintainer. In fact I have one local commit which I forgot to push... from Dec 2017. I wanted to brush it up a bit and have it released again. Yes, I buy CDs and rip them to mp3 or flac. Call me old school. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 20:35:11 CET Dr.-Ing. Christoph Cullmann wrote: > I and others tried to get more reviews done in the past, but actually I > merged more than once stuff that I reviewed but it did break the CI. That I hope we'll get fixed at some point. It's a big big advantage when you can get a CI run on reviews. I find it best when you get both humans and scripts looking at the code in a review. It helps a lot in having better quality reviews from the humans since they are relieved from the boring redundant nitpicking (catching warnings, basic code style, etc.). Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Friday, 29 March 2019 09:43:44 CET Volker Krause wrote: > On Friday, 29 March 2019 08:59:59 CET Kevin Ottens wrote: > > On Thursday, 28 March 2019 21:53:06 CET Alexander Neundorf wrote: > > > Having mandatory reviews for a central and complex component like > > > akonadi > > > looks like a very good and obvious idea. > > > > Yep. > > Looking at the 18.12 -> 19.04 timeframe the majority of changes to Akonadi > went through pre-commit review, even more so if you discard commits doing > release work (version bumps etc) or similar maintenance not touching the > actual logic. > > And specifically the changes that caused us the most headaches due to > introducing a nasty regression went through review. > > Sure, nothing is perfect, but I don't think code review in Akonadi is the > most pressing issue here. Fair enough. I was thinking more PIM in general though than Akonadi in particular. > > > OTOH if there is only one developer who is really expert for akonadi, > > > this makes it kind of unfeasible. > > > > That's the chicken and egg problem we're in concerning KDEPIM. The > > developer story is frankly really harder than most software out there > > which makes it unlikely for people to pick it over something else for > > contributions. That's in part tied to your next point below and partly > > tied to > > documentation, on- boarding etc. The unwillingness to be slowed down is > > getting in the way of fixing that situation: to be a desirable project to > > contribute to you need to spend time advocating, documenting and taking > > newbies by the hand until they become regular contributors. > > > > Yes it's tough, and TBH I'm guilty of not doing this more on my own > > projects. But on such a strategic piece of software like KDEPIM there's > > some responsibility in carrying those duties for the well being of the > > project. > > How to address the issue of bus factor ~1 components in PIM is the real > question here, I completely agree. But this is getting way off topic from > Ben's original issue, and for the wide range of recipients. Yes, I realized only too late that I kind of hijacked the thread somehow. I apologies about that. > Also, I don't think overly generic statements on that help us much, so maybe > let's discuss concrete steps for this at the sprint next week? Definitely. It's in part because I know the sprint is coming that I started to wave that particular flag. :-) I wish Laurent was there though, it'll make that particular discussion harder to conclude without him... Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 21:53:06 CET Alexander Neundorf wrote: > On 2019 M03 28, Thu 16:04:01 CET Boudhayan Gupta wrote: > > As a user, I simply do not want unreviewed crap running on my computer. > > Yes, crap, because no software engineer writes bug-free code all the time, > > and if you're so overconfident that you don't need reviews on even your > > one-liners, you're probably too overconfident to be writing good code > > anyway, so I'm going to operate on the presumption that if the code hasn't > > had more than one pair of eyeballs ever looking at it, it's crap. > > If you put it that strong, it's wrong. > Code which has not been reviewed is not generally "crap". Code which has > been reviewed is not generally "high quality". > Unreviewed code can be good, and often is good, and reviews, maybe > especially if they are mandatory, *can* be crappy: just pointing out > formatting issues, Oking the patch without understanding the big picture > (and feeling somewhat pressured to accept a patch because the review is > mandatory and otherwise you are blocking the other developer, etc.) Hell yeah, it's not a silver bullet. Actually it can be only one safety net among others. None of them are perfect, none of them will catch it all or be of good quality all the time, it's just about mitigating risks as much as possible. > > As a developer, I know that even one-liners, and especially one-liners, > > the sort where you think "meh, this is a tiny little thing, I don't have > > to be careful" are the ones that have the most dangerous typos and > > unintended bugs. > > That's also a wrong argument. one-liners are not especially prone to causing > most bugs. They may introduce bugs, but I think, since they are small, this > is less likely than for bigger patches. I don't think that's true. It's a question of complexity in the system really. In a trivial system indeed they are less likely to introduce bugs than for bigger patches... but as the software grows and complexity rises (especially with the multiplication of mutable states) one liners tend to be as error- prone as bigger patches. > ... > > > In a project like PIM, if the code hasn't been through review, which > > independent party do I trust to verify that you're not, for example, > > leaking my Google password to some world-readable tempfile? > > Having mandatory reviews for a central and complex component like akonadi > looks like a very good and obvious idea. Yep. > OTOH if there is only one developer who is really expert for akonadi, this > makes it kind of unfeasible. That's the chicken and egg problem we're in concerning KDEPIM. The developer story is frankly really harder than most software out there which makes it unlikely for people to pick it over something else for contributions. That's in part tied to your next point below and partly tied to documentation, on- boarding etc. The unwillingness to be slowed down is getting in the way of fixing that situation: to be a desirable project to contribute to you need to spend time advocating, documenting and taking newbies by the hand until they become regular contributors. Yes it's tough, and TBH I'm guilty of not doing this more on my own projects. But on such a strategic piece of software like KDEPIM there's some responsibility in carrying those duties for the well being of the project. > IMO this specific case is also a technical issue. Akonadi makes things > complicated (and it's already 13 years old, so it should be mature in the > meantime). Yes, it's byzantine really. And the user experience is still not great (to be polite), had to setup some new hardware recently and I was honestly almost to the point of throwing it all through the window. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 16:11:12 CET Friedrich W. H. Kossebau wrote: > Am Donnerstag, 28. März 2019, 14:33:59 CET schrieb laurent Montel: > > For example I works all days on kde (pim or other) when I wake up, or at > > noon after my lunch or the evening, I will not wait several days for a > > review because nobody has time to do it. > > > > (For example I make ~ 15 commits by days on pim/ruqola/framework, I don't > > want to wait several days/weeks until someone wants to review my patchs) > > Something might be lost in translation here, do you think, because you work > daily on code of KDE projects, and other people (so potential reviewers) do > not, this is an argument to do instant pushes of unreviewed commits? > > While I understand one can get impatient if not getting instant review of > changes one would like to depend on with further changes (I know this well > :) ), That particular point is in part a tooling problem though. Phab doesn't make this situation easy to handle. I have to do very naughty things to git and arc to deal with those. I'm guilty of often piling a dozen patches and rewriting extensively my history locally before the lots hits the first round of reviews. :-) > still this seems a flawed argument at least for part-time-contributors based > KDE projects, where the people one co-operates with only have time now and > then, like once per week. It could be seen unfair & ignorant to them if one > simply ignores their opinion, because one has more time reserved/ available. This is one of the big flaws of self-proclaimed meritocratic communities. You can out-commit someone and end up being the big decision maker hard to convince. Doesn't happen by malice in most cases I think, but it's a clear slippery slope. > Not sure where this is from, but often I have seen an unwritten policy > applied where people for a patch uploaded for review after one week of no > response add a ping and then wait another week, before finally pushing the > change. To me this seems a fair and reasonable policy, only ignores people > who are on vacation for some more weeks or otherwise inactive, but I have > not seen that ever been a real issue. Agreed. It makes sense. > Given the actual purpose of this thread, I would be more curious how you > have CI integrated in your workflow? And where things could be improved, to > prevent the current state of unhappiness for people who care about CI some > more? Given you said you work daily on KDE projects, it seems that the > brokeness of those projects on the KDE CI has slipped your attention. So > how does this happen, and how could this be prevented, other than people > having to hunt you down on irc and tell you :) Definitely interested in this as well. It's not the first time we have Ben having to escalate to some form of threat regarding the state of the CI in PIM components. Although it's clear from the kde-pim list that the CI is making a lot of noise there. Either we collectively became too good at ignoring those emails, or it's too verbose (after all it's one email per component per build type, it piles up quickly). Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 14:33:59 CET laurent Montel wrote: > I am against to force mandatory review, as it will create a lot of lose of > time, As I said, unpopular. > and we will not be sure that review is correct (see comment from > Volker about "transaction lock regression") This argument is absurd: "Hey, this vest isn't 100% bullet-proof, thus I'll walk in the middle of a war naked". > It's necessary to having a big team for doing it. I agree having a team of 1 for each KDE PIM component is a problem (and often the same person). > Ok a repo was broken, but it was just that fix was created in master not > 19.04, I didn't see nobody on IRC told us "this package is always broken", > when I saw it this morning I just cherry pick (2 seconds for fixing it). > > For example I works all days on kde (pim or other) when I wake up, or at > noon after my lunch or the evening, I will not wait several days for a > review because nobody has time to do it. > (we can see a review from zanshin for example https://phabricator.kde.org/ > D16210 we can see that David waited 2 months until having an answer...). Unfair, if you read the comments you'll see that this particular patch didn't appear in my dashboard for some odd reason (I suspect it comes from how arc associates a patch to a repository or not, but I digress...). > (For example I make ~ 15 commits by days on pim/ruqola/framework, I don't > want to wait several days/weeks until someone wants to review my patchs) > > I will not lose my time to review some code that I don't understand... I > never reviewed Akonadi patch as I don't understand this code, and I will > take time on it just for the pleasure as I prefer fixing bug or adding new > features in components that I maintain. > > When we have a big team as Qt team it can help but in pim component where we > don't have any redundant guy, we will lose a lot of time. Ah, the mythical big team... Because it's well known that on Qt the reviewers aren't stretch thin and that patches never end up weeks in limbo... Also you know that if you don't change your way of working you'll stay alone on your components? I know, chicken and egg... but all those commits and stuff randomly changing all the time doesn't help people to get in even if they'd want to. But you know that very well, we just discussed it half a dozen times in the past... > So for each increase version for each package I will wait a review. For sure > not. > > Each time that I will improve code as coding style I will wait that someone > wants to review... > > > I know that it's easy to write "make reviews mandatory" there is not an > impact about your work as we know that you are not really active on kde at > the moment... Right, let's bring something irrelevant to the discussion. You know it's mainly due to health issues the past few months right? (yes, March has been a real joy again... it keeps on giving) Besides, I apply mandatory reviews to myself on zanshin. > For sure I broke kcontact 2 days ago, but as a friend told me when I started > to work on kde "We can't create a bug when we don't code..." And this is true, writing code will create bugs, that's why responsible people like safety nets even to the price of throughput. Now can we use a more adult tone again? Maybe re-read Dan's email again who has a more balanced view despite being in a similar situation? Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 11:27:44 CET Daniel Vrátil wrote: > I'm completely fine with mandatory code review for everything and I'd be > happy to have this in PIM. I think the biggest problem in PIM to overcome > will be finding the reviewers - I dare say I'm currently the only one who > has at least a little idea about what's going on in Akonadi, so getting for > instance Laurent to review my Akonadi patches might be hard - same for me > reviewing Laurent's KMail patches. This will require non-trivial amount of > effort for all members of the community to gain deeper understanding of the > other components within the project and a willingness to step up and do a > code review even if they don't feel 100% comfortable with the code base. > But I believe that in the long run the benefits clearly out-weight the > cost. This! :-) > Btw we practice this policy at work and I do truly appreciate it, not only > as a huge learning experience but so many times just having a second pair > of eyes to glance over my code has revealed issues that sometimes almost > make me question my career choice as a programmer :-) I think this is > especially important for projects like PIM, where most of us contribute at > work in between waiting for CI and replying to 15 Slack threads or in the > evening after a long day And this too of course. I fully support this message. ;-) Cheers. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 10:35:37 CET Luca Beltrame wrote: > In data giovedì 28 marzo 2019 10:32:39 CET, Kevin Ottens ha scritto: > > OK, to be fair not 100% today's situation because of the above. It was > > based on best judgment maybe we're missing such a set of guidelines. I > > admit I'm slightly doubtful though. > > I can't claim it may work 100%, but I've seen other communities (many, many > years ago) where a "semi anarchy" replaced by "iron-gripped rules" from one > day to another actually killed them. I wouldn't call that iron grip from one day to the other though. It's not like we've not been working toward mandatory review for the past ten years or so. Most KDE projects de facto apply mandatory reviews AFAICT. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 10:08:54 CET Luca Beltrame wrote: > In data giovedì 28 marzo 2019 09:50:47 CET, Kevin Ottens ha scritto: > > I'd argue we're loosing more with the current state of PIM than we'd loose > > with mandatory reviews. > > Perhaps, instead of an all-or-nothing approach, why not a minimal set of > "requirements" that would require a review? Yes, it requires more discipline > from those involved, but at least it will help people getting "ingrained" > with the concept without being a wall. I'm almost tempted to reply "been there, done that". It's kind of the situation we have today. > Examples: > > - No review: typo fixes, compile errors, version bumps (internal) > - Review: build system adjustments (perhaps CC some people knowledgeable in > this case), non-trivial changes like patches > - "Deprecation" removals (as in the casus belli here) - review if touching > more than a handful of files / multiple repos > > (list made by someone who has a passing knowledge of C++, so feel free to > rip me to shreds) OK, to be fair not 100% today's situation because of the above. It was based on best judgment maybe we're missing such a set of guidelines. I admit I'm slightly doubtful though. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 09:41:29 CET Luca Beltrame wrote: > In data giovedì 28 marzo 2019 09:29:22 CET, Kevin Ottens ha scritto: > > at your screen or pair with you" in the past. Clearly this compromise gets > > somewhat exploited and that's especially bad in the case of a fragile and > > central component like KDE PIM. > > I'm not sure I agree. I can't speak for seasoned developers, but I've found > myself in a situation (more than once) where the fix is trivial (compile > error, missing ";", etc) and being forced to go through review would (IMO) > unnecessarily raise friction. I don't fully disagree with this (although I'd have stories on nefarious typos even for what was supposed to be a "trivial fix"). But it becomes a question of trade-off, IOW "how hurtful to the project mandatory reviews?" vs "how hurtful to the project a central component being very regularly broken?". I'd argue we're loosing more with the current state of PIM than we'd loose with mandatory reviews. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 09:16:11 CET Ben Cooksley wrote: > Please note that the commits in this instance were pushed without > review, so restrictions on merge requests wouldn't make a difference > in this case unfortunately. Maybe it's about time to make reviews mandatory... I know it's unpopular in KDE, and I advocated for "don't force a tool if you can get someone to look at your screen or pair with you" in the past. Clearly this compromise gets somewhat exploited and that's especially bad in the case of a fragile and central component like KDE PIM. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: Importing kdiff3 - was - Re: Aw: Re: KDE inclusion
Hello, On Thursday, 25 January 2018 22:35:37 CET Albert Astals Cid wrote: > El dijous, 25 de gener de 2018, a les 9:01:10 CET, Kevin Ottens va escriure: > > On Thursday, 25 January 2018 00:08:03 CET Albert Astals Cid wrote: > > > As I did with the last person that also was confused and annoyed by all > > > this burocracy, just ask me any question you may have. > > > > Oh come on... the bad mean bureaucracy argument now. Wanna look at the > > Eclipse incubation process? Or the Apache one? > > Can I use the "if all your friends jump from a balcony will you do it" > defense? Not really since my point was more that what we have in place is very very far from bureaucracy not that we should replicate other's bureaucracy. If you want an example of bureaucracy look at those friends who jump from a balcony. ;-) > > Seriously it's just about having a person already within the community > > making sure the new project needs get catered to and also making sure the > > new project is on the right path to put in place rules and procedures > > compatible with the rest of the community (and the Manifesto). > > But how do you find that person? You're just an 'outsider', how do you find > a random person to be your incubator guy? Because as it happens, it's the > second time in a month or something that i have to volunteer. Ah! That is interesting feedback. You're correct that we're currently assuming that someone will step in to do that and that there's enough of us and that we're responsible enough to do that when we see something we're interested in. Personally for kdiff3, I'd have expected Kevin Funk to end up doing it, indeed he was first responder with "I'd love to see kdiff3 being adopted by KDE again". To me he sounded like a perfect sponsor. I'd like to see that fixed. Right now, I'm not sure how, but if you're the only one indeed caring about new projects getting in, we have a more general community problem, it's just that the incubator makes it visible... > I think it's much easier if we had guidelines and the rest was just "ask in > kde-devel mailing list if you have further questions", It'd be easier, but not better. Because then it's no different than "ask the GitHub support if you have further questions", and it's not what it's about. In my previous email I mentioned this is *also* for the "sponsor" to touch base with the joining project to verify it's getting into fruition to *be* a KDE project (which is not just about having a repository on our infrastructure)... I know, pesky people and culture thing. > and sure if you find a dedicated person for you, great, but requiring it > feels weird, and also makes it for less scalability, as an example I already > have an email from Michael that was sent only to me but anyone else in this > list would have been able to answer, but he had to wait at least 14 hours > for me to have time to answer it. Maybe that needs to be made clearer in the wiki? I'd expect the sponsor to push the involved persons to ask these type of questions on public mailing lists indeed. One on one discussions are likely to happen but they must be the minority of the communication going on. The sponsor in that case is the fail safe mechanism to make sure an answer indeed happens in those public forums or trying to solve the case if no answer happened for some reason. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Importing kdiff3 - was - Re: Aw: Re: KDE inclusion
Hello, On Thursday, 25 January 2018 00:08:03 CET Albert Astals Cid wrote: > El dimecres, 24 de gener de 2018, a les 17:34:16 CET, Kevin Funk va escriure: > > On Wednesday, 24 January 2018 16:24:10 CET Michael Reeves wrote: > > > A little confused on where to start with this sponsor thing. > > > > Huh? 'sponsor thing'? :) > > I guess it's regarding the > https://community.kde.org/Incubator/Incubation_Process > > Which to my understanding was supposed to be a voluntary thing but it seems > some people are forcing it on every single new project. Was supposed to be for any project born outside the community and joining in. So not quite so voluntary. > As I did with the last person that also was confused and annoyed by all this > burocracy, just ask me any question you may have. Oh come on... the bad mean bureaucracy argument now. Wanna look at the Eclipse incubation process? Or the Apache one? Seriously it's just about having a person already within the community making sure the new project needs get catered to and also making sure the new project is on the right path to put in place rules and procedures compatible with the rest of the community (and the Manifesto). Call it bureaucracy if you wish, but I think it's good to avoid people dropping code in a corner to then be ignored by everyone and wondering what to do next. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Reviving KAudioCreator
Hello, On Tuesday, 26 December 2017 23:18:00 CET Albert Astals Cid wrote: > One kind-of-big bug i'd like fixed is that it doesn't realize the encoder > command line is not there, i was waiting for like 5 minutes wondering why it > took so much to encode until i realized that i don't actaully have the flac > command line installed. Yes, I encountered that one indeed. I'll try to take a look. Otherwise I ripped and encoded a few CDs successfully over the week-end. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Reviving KAudioCreator
Hello, On Friday, 22 December 2017 10:59:55 CET Boudhayan Gupta wrote: > I did a little work on KCompactDisc about two years ago (and also > looked at KAudioCreator), and then realised it hadn't been working for > a long time. [...] I think it was due to the audiocd kio not being available in the KF5 world, but now it's there. I'm right now ripping a CD and getting it encoded to OGG Vorbis just fine using current KAudioCreator master. There are a few paper cuts but really minor stuff. I don't think we need to go through expensive rewrites and such. Can likely fly with minor adjustments. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Reviving KAudioCreator
Hello all, I happen to be one of those poor souls who still rip CDs from time to time. I'm using Dolphin for that right now, but I miss the convenience of using KAudioCreator a while back. It looks like it's not released at all anymore. After a quick glance at the repository, it seems to be in a somewhat good shape (at least it builds and starts, I didn't push further yet). Then, I'd like to revive it and have it part of KDE Applications. Anyone with an objection about that? If none, how do we proceed? I see a couple of things which need to be improved a bit so I'll try to work on those in the meantime. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KDE Review: Rust Qt Binding Generator
Hello, On Monday, 4 September 2017 09:43:46 CEST Jos van den Oever wrote: > Op maandag 4 september 2017 07:46:28 CEST schreef Kevin Ottens: > > On Sunday, 3 September 2017 18:14:49 CEST Jos van den Oever wrote: > > > [...] > > > The idea of this binding generator is that you write each part in the > > > most appropriate language. Rust bindings for Qt are hard to get right > > > and will still have caveats for a while. With this generator, you write > > > the UI in C++ or QML. The generated code has no dependencies apart from > > > Qt Core and the Rust crate libc. > > > > So what's the intent with this one? Is it a stop gap measure until > > cpp_to_rust is more complete? > > https://github.com/rust-qt/cpp_to_rust > > cpp_to_rust is an ambitious project. cpp_to_rust lets you call Qt libraries > from a Rust project. This means that the qt_core, qt_gui etc crates have to > take care of thread-safety and ownership. Qt has quite a few ways of dealing > with ownership. A QObject is responsible for destroying and deallocating > its children. QString is value type with a reference-counted memory block > inside. > > I spent time on another binding project and sent patches to it, but it was > not active anymore. Then I realized that it is early for depending on a > project that tries to wrap Qt as a Rust crate. > > If you'd like to use Rust in an existing KDE project, you'd not take that > approach either. You'd call new Rust code from your Qt code. cpp_to_rust > focusses the other way around. > > The interesting part of writing Qt code is custom implementations of QObject > and QAbstractItemModel that you pass to Qt elements. QComboBox, QTableView, > QListView all take QAbstractItemModel implementations. > > So the binding generator, which I'm fine to call a stop gap measure, Note that I didn't mean that to diminish your work, I was really wondering if your intent was to see your binding generator as something temporary or something with longer term plans. Looks like it's longer term which sounds good. > focusses on that part. You implement QObject and QAIM with Rust code that > does not feel like Qt, but feels like Rust code. > > For example, here is an implementation of a QAbstractItemModel that is used > as model in QtChart and (Q)TableView in the demo. It does not look like a > QAIM at all. > > https://cgit.kde.org/scratch/vandenoever/rust_qt_binding_generator.git/tree/ > demo/rust/src/implementation/time_series.rs > > Of course, it's a bit simple, because it's static data. > > When cpp_to_rust has a stable release and is easy to use from exisiting C++/ > CMake projects, this project can be ported to use that. The code that > generates Qt implementations could then be a Rust macro. Thanks a lot for the extra insights. Makes sense. > > Are you contributing to it as well? (I started patching it locally but > > still need to clean up my work for upstream contribution) > > No, I contributed to a previous binding project. cpp_to_rust is an > attractive idea because it allows you to code only in Rust. Enticing as the > idea is, I wanted something that works now. In addition, I like the idea of > separating UI and logic. Sure, it always make sense to separate them, I don't perceive this as an argument for different languages though. > > > [...] > > > This project is not a typical C++ KDE project, but I hope it can be part > > > of KDE anyway. > > > > Of course take the above more as curiosity and wondering how that will fit > > regarding the larger Rust ecosystem. I don't see a problem with things > > like this to be part of KDE. > > Cool. Thanks for taking a look. Interesting stuff anyway, looking forward to it having stable releases. :-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KDE Review: Rust Qt Binding Generator
Hello, On Sunday, 3 September 2017 18:14:49 CEST Jos van den Oever wrote: > [...] > The idea of this binding generator is that you write each part in the most > appropriate language. Rust bindings for Qt are hard to get right and will > still have caveats for a while. With this generator, you write the UI in C++ > or QML. The generated code has no dependencies apart from Qt Core and the > Rust crate libc. So what's the intent with this one? Is it a stop gap measure until cpp_to_rust is more complete? https://github.com/rust-qt/cpp_to_rust Are you contributing to it as well? (I started patching it locally but still need to clean up my work for upstream contribution) > [...] > This project is not a typical C++ KDE project, but I hope it can be part of > KDE anyway. Of course take the above more as curiosity and wondering how that will fit regarding the larger Rust ecosystem. I don't see a problem with things like this to be part of KDE. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Sunday, 2 July 2017 12:33:47 CEST Albert Astals Cid wrote: > El diumenge, 2 de juliol de 2017, a les 1:58:52 CEST, Kevin Ottens va > > It's been a week now without objection or further change requests. It's > > been in kdereview for three weeks now. Shall we more to extragear/pim > > now? > > +1 Zanshin now has been moved to extragear/pim. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Sunday, 2 July 2017 13:52:48 CEST Sandro Knauß wrote: > > 2) the third one (libkdepim) I'm forbidden to link against since it's > > private API to kdepim (turned into a dumping ground apparently...). > > > > Obviously, as soon as libkdepim is cleaned up (which I regularly hear it's > > supposed to happen) and features are moved in proper frameworks I'll drop > > it from the 3rdparty folder. Didn't happen yet... > > Well kdepim is a open group. kdepim is not giving API stability because, we > need space to cleanup, but the team is not very big, so it takes time. I think I know that quite well. > But I don't see why you are not just link against the relevant parts of > kdepim and remove the copy. And than tell kdepim that you are using these > files, so the team can take that into account when touching the files. As I mentioned earlier I don't because that is private API meant only for consumption within kdepim applications. Depending on such API is wrong. > Additionally you can add tests and cleanup the code yourself. That would be assuming I have the bandwidth for that: I don't. > As fallback you can still copy the files as temporally solution in future, > if things break. > > The relevant point for me is that copies of code have a slash back, > sometimes fast sometimes it takes much time. Sure, I'm not in love with the current situation either. > But what I can say from my work in Debian is that often Debian needs to > coordinate the discussion to get rid of copies, that could have been avoided > if the different projects had been talking directly with each other. > > For me the existence of those copies and no discussions with kdepim are a > -1 for moving it out of Review. You're assuming this wasn't discussed previously. It's been discussed a long time ago in person. It's not like no one in kdepim knew about it. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Sunday, 25 June 2017 14:00:05 CEST Kevin Ottens wrote: > On Thursday, 8 June 2017 09:36:51 CEST Kevin Ottens wrote: > > OK, this time it's the right one. :-) > > > > Zanshin is now in kdereview and aiming for extragear/pim. Please review > > away! > > > > Thanks in advance. > > So I pushed just now all the patches mentioned in this thread. They should > address all the feedback I got so far *except* the license "issue" (means > it's effectively GPLv2) since I didn't get a reply from all the necessary > people yet to allow relicensing. I don't think I can do much more about > that one right now. > > Any issue still preventing the move in extragear/pim? It's been a week now without objection or further change requests. It's been in kdereview for three weeks now. Shall we more to extragear/pim now? Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Thursday, 8 June 2017 09:36:51 CEST Kevin Ottens wrote: > OK, this time it's the right one. :-) > > Zanshin is now in kdereview and aiming for extragear/pim. Please review > away! > > Thanks in advance. So I pushed just now all the patches mentioned in this thread. They should address all the feedback I got so far *except* the license "issue" (means it's effectively GPLv2) since I didn't get a reply from all the necessary people yet to allow relicensing. I don't think I can do much more about that one right now. Any issue still preventing the move in extragear/pim? Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Friday, 23 June 2017 16:11:12 CEST Luigi Toscano wrote: > On Friday, 23 June 2017 16:08:31 CEST Kevin Ottens wrote: > > On Tuesday, 20 June 2017 22:14:33 CEST Kevin Ottens wrote: > > > On Monday, 19 June 2017 21:50:16 CEST Luigi Toscano wrote: > > > > [...] > > > > I'm not sure why you didn't like the above solution. > > > > > > Just more work over time, and I don't have the bandwidth ATM. Typically > > > we > > > tend to assume ki18n and a single catalog as the common case (and > > > rightly > > > so), so does releaseme assume that too? And then I have to think about > > > both > > > files for shipping, etc. > > > > > > I just don't have the energy to think all that through so I'd rather go > > > the > > > lazy and easy path with the patch I did. > > > > > > > Now, can we properly discuss this? I don't want people coming back and > > > > saying that a solution was forced for $reasons when it was not forced > > > > at > > > > all. (that said, KI18n is better, but again you don't need to use it). > > > > > > > > > This one switches it all to i18n: https://phabricator.kde.org/D6283 > > > > > > > > I'm going to put a -1 until we discuss this properly. > > > > > > Hope the above clarifies my reasons a bit. > > > > > > In a nutshell: tr() was used for an hypothetical mobile port, this port > > > is > > > still not in sight with the bandwidth I currently have and tr() is > > > creating > > > me troubles mainly due to the kparts plugins; so either I drop said > > > plugins > > > or I switch to i18n to be like everyone else. I'm going for being like > > > everyone else. > > > > > > It can always be revisited later if there's really a mobile port or such > > > emerging. > > > > Can we lift the -1, review that patch and move on now? > > There is a legitimate request change linked to the -1, as stated in the > review. Ooops, sorry I didn't spot it somehow. Patch is now updated. :-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Tuesday, 20 June 2017 22:14:33 CEST Kevin Ottens wrote: > On Monday, 19 June 2017 21:50:16 CEST Luigi Toscano wrote: > > [...] > > I'm not sure why you didn't like the above solution. > > Just more work over time, and I don't have the bandwidth ATM. Typically we > tend to assume ki18n and a single catalog as the common case (and rightly > so), so does releaseme assume that too? And then I have to think about both > files for shipping, etc. > > I just don't have the energy to think all that through so I'd rather go the > lazy and easy path with the patch I did. > > > Now, can we properly discuss this? I don't want people coming back and > > saying that a solution was forced for $reasons when it was not forced at > > all. (that said, KI18n is better, but again you don't need to use it). > > > > > This one switches it all to i18n: https://phabricator.kde.org/D6283 > > > > I'm going to put a -1 until we discuss this properly. > > Hope the above clarifies my reasons a bit. > > In a nutshell: tr() was used for an hypothetical mobile port, this port is > still not in sight with the bandwidth I currently have and tr() is creating > me troubles mainly due to the kparts plugins; so either I drop said plugins > or I switch to i18n to be like everyone else. I'm going for being like > everyone else. > > It can always be revisited later if there's really a mobile port or such > emerging. Can we lift the -1, review that patch and move on now? Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Saturday, 10 June 2017 15:08:36 CEST Kevin Ottens wrote: > On Thursday, 8 June 2017 13:03:35 CEST Jonathan Riddell wrote: > > If I stop Akonadi it silently stops working, an error message might be > > informative. > > I'll see what can be done, I'll need to investigate on how best to address > it. Is it a blocker for getting out of kdereview? If not please open a bug > report about it. Now addressed with the following patch: https://phabricator.kde.org/D6325 I think it was the last comment I didn't really address so far. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Monday, 19 June 2017 21:50:16 CEST Luigi Toscano wrote: > Kevin Ottens ha scritto: > > On Monday, 19 June 2017 18:56:39 CEST Luigi Toscano wrote: > >> On Monday, 19 June 2017 18:50:23 CEST Kevin Ottens wrote: > >>> On Tuesday, 13 June 2017 00:07:01 CEST Albert Astals Cid wrote: > >>>> Have you read the page that speaks about how to write Messages.sh > >>>> files? > >>>> It's quite good. Please read it and explain what you don't understand. > >>> > >>> It's more that I don't quite see clearly the distribution of the .po and > >>> such after the Message.sh is run. > >>> > >>> That being said, wouldn't that be more natural to either extend > >>> extractrc > >>> to spit out mock QObject::tr() calls? Or to have the Message.sh run perl > >>> on the file? > >>> > >>> Sounds cleaner to me than having several catalogs loaded for an > >>> otherwise > >>> self-contained application. > >> > >> I haven't checked the code, but the idea is that: > >> - messages handled by Qt translation system should end up in the > >> _qt file; > >> - messages from KI18n should end up in a file or a set of files named as > >> you want (you just need to set the proper domain which matches the file > >> name). > >> > >> So please try to follow these guidelines. If the application already uses > >> KI18n directly or indirectly, I would just use it for everything. > > > > I find unfortunate we actively discourage being able to work without ki18n > > in such case. But OK, got better things to do I'll stop fighting this > > one. > We are not discouraging anyone. Technically we do, too many hoops to go through. I didn't mean *you* were discouraging me, I'm just saying that the fact that I have kparts in the mix makes it somewhat harder. > You can definitely work without KI18n, or mixing Qt-only modules with > KI18n-managed modules. Marble and Step are two example of this, and this is > not because we like it or not but there are specific technical reasons for > it. Sure, I guess we'd be more similar to the Marble case. > In this case, every module which links to kparts should use KI18n, but you > can have pure Qt libraries (even static) which uses ::tr. And of course you > need two translations files. > > I'm not sure why you didn't like the above solution. Just more work over time, and I don't have the bandwidth ATM. Typically we tend to assume ki18n and a single catalog as the common case (and rightly so), so does releaseme assume that too? And then I have to think about both files for shipping, etc. I just don't have the energy to think all that through so I'd rather go the lazy and easy path with the patch I did. > Now, can we properly discuss this? I don't want people coming back and > saying that a solution was forced for $reasons when it was not forced at > all. > (that said, KI18n is better, but again you don't need to use it). > > > This one switches it all to i18n: https://phabricator.kde.org/D6283 > > I'm going to put a -1 until we discuss this properly. Hope the above clarifies my reasons a bit. In a nutshell: tr() was used for an hypothetical mobile port, this port is still not in sight with the bandwidth I currently have and tr() is creating me troubles mainly due to the kparts plugins; so either I drop said plugins or I switch to i18n to be like everyone else. I'm going for being like everyone else. It can always be revisited later if there's really a mobile port or such emerging. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Monday, 19 June 2017 23:11:09 CEST Albert Astals Cid wrote: > That makes no sense, the kxmlgui code will call i18n(), so you need to have > it in a .mo file not on a .ts file. Fair enough, I abandoned that patch, did another one to switch to i18n everywhere instead: https://phabricator.kde.org/D6283 Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello,
On Monday, 19 June 2017 21:49:26 CEST Jonathan Riddell wrote:
> On Mon, Jun 19, 2017 at 09:36:39PM +0200, Kevin Ottens wrote:
> > Looks like I just didn't clone at the right time.
> >
> > That said, there's something fishy with the signature:
> > https://paste.kde.org/pgh6b1em7
>
> releaseme doesn't do anything special with gpg, it just runs
> gpg2 --armor --detach-sign -o #{sigfile} #{file}
>
> So does gpg2 work for you signing a text file?
Yep it does and the signature is valid... it's just that it somehow returns
with an exit code of 2 here and not 0. Really odd...
Regards.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Monday, 19 June 2017 18:56:39 CEST Luigi Toscano wrote: > On Monday, 19 June 2017 18:50:23 CEST Kevin Ottens wrote: > > On Tuesday, 13 June 2017 00:07:01 CEST Albert Astals Cid wrote: > > > Have you read the page that speaks about how to write Messages.sh files? > > > It's quite good. Please read it and explain what you don't understand. > > > > It's more that I don't quite see clearly the distribution of the .po and > > such after the Message.sh is run. > > > > That being said, wouldn't that be more natural to either extend extractrc > > to spit out mock QObject::tr() calls? Or to have the Message.sh run perl > > on the file? > > > > Sounds cleaner to me than having several catalogs loaded for an otherwise > > self-contained application. > > I haven't checked the code, but the idea is that: > - messages handled by Qt translation system should end up in the _qt > file; > - messages from KI18n should end up in a file or a set of files named as you > want (you just need to set the proper domain which matches the file name). > > So please try to follow these guidelines. If the application already uses > KI18n directly or indirectly, I would just use it for everything. I find unfortunate we actively discourage being able to work without ki18n in such case. But OK, got better things to do I'll stop fighting this one. This one switches it all to i18n: https://phabricator.kde.org/D6283 Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Monday, 12 June 2017 16:48:26 CEST Jonathan Riddell wrote: > On 10 June 2017 at 14:08, Kevin Ottens <er...@kde.org> wrote: > >> You have a release script in scripts/release.sh, consider using > >> kde:releaseme as extracting translations can be quite faffy and > >> releaseme does all that for you. > > > > I tried that recently but didn't manage to get it to work at all. Failed > > with a backtrace leading to some obscure Ruby dependency and got stuck. > > Any guidance is welcome there, I'm especially interested because of the > > translation extraction bits which I do a bad job at since the > > beginning... > releaseme shouldn't need any external dependencies except Ruby so post > us the backtrace and I'll take a look After pulling again today it now works much better! :-) Looks like I just didn't clone at the right time. That said, there's something fishy with the signature: https://paste.kde.org/pgh6b1em7 > >> On my KDE neon User Edition install if I run Kontact it appears fine > >> but on closing Kontact it crashes, this doesn't happen if I don't have > >> Zanshin installed. > > http://paste.ubuntu.com/24841577/ Should be fixed with: https://phabricator.kde.org/D6284 Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Tuesday, 13 June 2017 00:07:01 CEST Albert Astals Cid wrote: > Have you read the page that speaks about how to write Messages.sh files? > It's quite good. Please read it and explain what you don't understand. It's more that I don't quite see clearly the distribution of the .po and such after the Message.sh is run. That being said, wouldn't that be more natural to either extend extractrc to spit out mock QObject::tr() calls? Or to have the Message.sh run perl on the file? Sounds cleaner to me than having several catalogs loaded for an otherwise self-contained application. Here is my attempt at running perl on the file to inject tr instead of i18n: https://phabricator.kde.org/D6276 Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Thursday, 8 June 2017 22:12:10 CEST Albert Astals Cid wrote: > Sincerely i'd just suggest to kill the 3rdparty folder altogether, if you're > concerned about people not being able to compile your thing you're better > server just providing an appimage/snap/flatpack. It's more that: 1) two of them are generally not packaged, only for the tests and don't seem to care much about API compatibility assuming they're in the source tree (cucumber-cpp and mockitopp) so I just deal with it as they seem to expect; 2) the third one (libkdepim) I'm forbidden to link against since it's private API to kdepim (turned into a dumping ground apparently...). Obviously, as soon as libkdepim is cleaned up (which I regularly hear it's supposed to happen) and features are moved in proper frameworks I'll drop it from the 3rdparty folder. Didn't happen yet... Hope that clarifies. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Thursday, 8 June 2017 19:24:54 CEST Albert Astals Cid wrote: > El dijous, 8 de juny de 2017, a les 9:36:51 CEST, Kevin Ottens va escriure: > > OK, this time it's the right one. :-) > > > > Zanshin is now in kdereview and aiming for extragear/pim. Please review > > away! > > Oh, you use kparts, but use a tr() based system instead of a i18n one. > > Can I ask why? Because it got started while KF5 was on the radar and couldn't tell what would happen of i18n. Also I don't use any of the i18n features and I want to keep the dependencies as minimal as possible to make a move on a mobile target easier if need be. > This current setup makes the strings of the *.rc files untranslatable since > extractrc creates mock i18n() calls. > > If you really really really want to keep the tr() based system I'd like to. > I guess you could have a new .po catalog for the messages contained in the > .rc files and also load that one. I'm a bit clueless there, I think I need some hand holding. Could you be a bit more specific on how this is done? Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Zanshin is in kdereview
Hello, On Thursday, 8 June 2017 13:03:35 CEST Jonathan Riddell wrote: > There's some GPL 2 only files in 3rdparty/kdepim, if they are used it > means the applications can only be copied as GPL 2, consider > contacting the copyright holders to fix this as it doesn't match the > rest of the source. (And fix it in kdepim if the same files are there > with the same licence.) Some of the people involved are listed in the relicense check script, I sent an email to the other ones in order to complete our database. Let's wait and see now... > You have a release script in scripts/release.sh, consider using > kde:releaseme as extracting translations can be quite faffy and > releaseme does all that for you. I tried that recently but didn't manage to get it to work at all. Failed with a backtrace leading to some obscure Ruby dependency and got stuck. Any guidance is welcome there, I'm especially interested because of the translation extraction bits which I do a bad job at since the beginning... > There's no documentation. I'm unsure how strong a requirement this is > these days. I honestly don't have the bandwidth to maintain such documentation at the moment. > Is Todo a word? I think it should be but the dictionaries I checked > haven't caught up with it. Maybe KDE can be at the forefront of > English linguistic development here. Addressed by: https://phabricator.kde.org/D6170 > Use title case on actions (menu items and buttons), "Next page" should > be "Next Page" etc Addressed by: https://phabricator.kde.org/D6171 > Single key shortcut for Move item is unusual, check with usability > designer types if that's ok. I'm very much attached to this. It's in fact mimicking what KMail does. > If I stop Akonadi it silently stops working, an error message might be > informative. I'll see what can be done, I'll need to investigate on how best to address it. Is it a blocker for getting out of kdereview? If not please open a bug report about it. > On my KDE neon User Edition install if I run Kontact it appears fine > but on closing Kontact it crashes, this doesn't happen if I don't have > Zanshin installed. Do you have more information about that? I got to admit I don't use this plugin and I'm regularly thinking about just dropping it, opinions welcome. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Zanshin is in kdereview
Hello, OK, this time it's the right one. :-) Zanshin is now in kdereview and aiming for extragear/pim. Please review away! Thanks in advance. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: zanshin for kdereview
Hello, On Tuesday, 6 June 2017 11:29:00 CEST Aleix Pol wrote: > On Sat, Jun 3, 2017 at 9:01 AM, Kevin Ottens <er...@kde.org> wrote: > > Zanshin has been around for a while and I should have requested it to move > > to Extragear a long time ago but somehow forgot. The discussion regarding > > the next gen CI reminded me of that. > > > > I hereby request Zanshin to be moved out of playground and into kdereview > > so that it gets the usual review period. The aim is to have in in > > extragear/pim in the end. > > I'm pretty sure moving to kdereview is something to ask to sysadmin. > https://phabricator.kde.org/u/systickets Ah damn. > Then once it's there you request the move here saying it's in > kdereview, waiting to go to extragear/pim. Thanks for the tip. > PS: ah, bureaucracy! :D Yes, and I don't think it was mentioned in our wiki really, or I missed it somehow. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
zanshin for kdereview
Hello, Zanshin has been around for a while and I should have requested it to move to Extragear a long time ago but somehow forgot. The discussion regarding the next gen CI reminded me of that. I hereby request Zanshin to be moved out of playground and into kdereview so that it gets the usual review period. The aim is to have in in extragear/pim in the end. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Next Gen CI Will Be Moving to Production Shortly: Upcoming Changes
Hello, On Saturday, 6 May 2017 11:37:51 CEST Ben Cooksley wrote: > Which brings me to the third point of attention. We'll only be adding > projects to the Next Gen CI system at their request going forward. For > Frameworks, Applications and Plasma this is something which we're > essentially assuming we're going to receive from their release > managers, so we'll take care of defining the initial Products for > those. For Extragear projects, please respond to this thread if you'd > like CI coverage (to continue) to be provided to you. Yes please! I'd like Zanshin and Kairo to keep being covered. I don't mind being guinea pig on anything you would see fit. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Fwd: Plasma Mobile Components -> Kirigami (?)
Hello, On Tuesday, 1 March 2016 18:30:23 CET Marco Martin wrote: > [...] > right now They are called Plasma mobile components, but the concern is > that "it depends on plasma", it's intended just to be used on plasma, > but that's not true. > Another name was proposed: Kirigami, below the rationale by the > proposal first written by Thomas. > > I'm asking here because: as developers of Qt application, If you were > to consider things to use to port your applications to a mobile > interface, what would you prefer? I think that's a good move... and since I felt alone picking up names coming from Japanese I totally support the proposed Kirigami. :-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Phabricator: Make it happen already!
Hello all, So we've been evaluating different options to modernize our tooling, and for some reason it looks like we're still waiting on some external pressure to pick one. I'll then try to be this external pressure with this war cry: Phaaab! Make it happen already! It is basically what I reported during the Phabricator BoF at Akademy this year. For some obscure (to me) reason, I ended up being one of those who tried all the contenders, and to me, Phabricator is the best fit for our community[*]. Also recently I'm seeing a surge of use in the test instance, so I'd say it is time to get it out of limbo and make it official. Sysadmins, could we move forward with it please and start migrating for real? Thanks for your attention. Regards. [*] Obviously I'm leaving plenty of details here, I'm not debating the why, I'm just trying to get the ball rolling. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: [Kde-pim] The Future or KDE PIM Releases
Hello, On Tuesday 14 April 2015 09:44:19 Sandro Knauß wrote: What's meant by KDE Accounts? well we also had a look into the code. It is a resource that will adds all local users from kde to your kaddressbook. Oooh, that one... it's very important to me, I rely a lot on it. Can we release it? I'm even willing to be signed up as maintainer. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Build dependency issues with kdesrc-build
Hello, On Friday 06 February 2015 15:11:22 Kevin Funk wrote: On Thursday 05 February 2015 22:16:54 Michael Pyne wrote: kdesrc-build will reorder modules into the right build order (assuming the needed metadata in kde-build-metadata is present). However as of now it only reorders modules you pull into the build list, so you still need to specify dependencies somehow. E.g. if you only asked to build plasmate, kdesrc-build wouldn't pull kdevplatform for you, but if you asked to build both kdesrc-build would do it in the right order. Question: Can't we add an option that does exactly that? Anything that'd prevent us to do so? Proposal: Build everything that is a dependency of the package passed to kdesrc-build. I personally would like to have this as well. A first time user (I want to hack on plasmate) could then just invoke something along: $ kdesrc-build --include-deps plasmate Yes, that would be extremely useful. I got students who are preparing to hack on zanshin and I witnessed them struggle with their kdesrc-buildrc quite a bit. It would be much smaller and easier to write to start with such an option (I'd go for an option at the module or module-set level more than on cli though). Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Another proposal for modernization of our infrastructure
Hello, First of all, thank you Boud for the wise words. On Tuesday 03 February 2015 11:17:59 Boudewijn Rempt wrote: On Mon, 2 Feb 2015, Milian Wolff wrote: Sigh, I find it highly sad to read this over and over again. Well, this whole discussion makes me extremely sad. What people have to learn is that _arguments_ only go so far. People can feel they're double-plus extra-super right, and still at one point they have to accept that they're not going to change the other people's point of view. And not respecting or ignoring other people's point of view will lead to bullying or pushing people away. For the record those numerous mega-threads already pushed some people away (I'm aware of several people whom motivation drastically declined just reading them). It'd be nice if everyone would take a deep breath and realize: it is just a tool dammit! So, here is my point of view, put very simply: * replacing reviewboard with gerrit will mean fewer contributors to many of the projects KDE hosts. * following from that, projects that want to stay alive and relevant will move away from the kde infrastructure. * which makes gerrit a Bad Thing. This is what I am sure _will_ happen, no matter how much anyone argues that gerrit is cool, can be cool, will be cool, won't be as uncool as it's for Qt, how lovely gerrit's git integration is, how nice it is to train people to contribute to Qt, that nobody has tested phabricator yet and so on ad infinitum. I've read it all, and I'm not convinced. There are people who like gerrit and would love to use it. I accept that. Agreed. I also accept your opinion that gerrit would be a Bad Thing even though I'm not convinced by that either. Simply put: I'm not convinced gerrit would be super-good or super-bad for us. It's likely something in between. But there is not going to be a broadly supported consensus that gerrit is cool and should be used by KDE in the development workflow. There is not going to be a consensus that gerrit should replace reviewboard, sorry, no matter over how many mails the same arguments get rehashed. That's something people who like gerrit have to accept. Hear! Hear! Also it is just a tool dammit! Don't forget: If there are people who don't like gerrit you're not a fool because you like it. Now, phabricator might be just as crappy, though if Blender uses it... (But that's the same argument as Qt uses it is for gerrit and just as invalid), but let's first _test_ it, as Ben proposed. Yes please... No need for more noise on the matter until we have the experiment done. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Sysadmin report on the modernization of our infrastructure
Hello, On Wednesday 21 January 2015 17:12:07 Ben Cooksley wrote: As promised in the earlier thread, i'd like to present the sysadmin report on the state of the infrastructure surrounding our code. It contains a detailed summary of what is broken with our existing systems, why change is necessary and an evaluation of the options we considered. We have also made a proposal based on our evaluations and the wishlist of functionality drawn up the community. Please find it attached - and let us know what you think. Feedback is welcome. At last some movement in that space that's really nice. I think I've been annoying the sysadmin team with our current tools for a while now, so I can only propose Zanshin as one of the test projects. I especially appreciate the global approach you took, indeed we have to go the forge approach not focus on code hosting + review only. It looks like Phabricator is a nice move in that direction to have something really consolidated and not plenty of disjoint tools. BTW, since we didn't open a kanboard for Zanshin yet, we're totally up to test the task tracking of Phabricator. In fact the more tools we get enabled for our test the better so that we can cover wide on the features. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Changes to branch management
On Wednesday 24 December 2014 13:57:15 Ben Cooksley wrote: Unfortunately i'm not sure if Gitolite's ACL mechanisms let us differentiate between tags and branches so if we allow anyone to delete branches they'll probably be able to do the same for tags. Then it's definitely something to pay attention to. I don't think we're as well structured for tags than we are for branches accross the board. Especially for tagging releases I don't think we have a consistent naming scheme. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Changes to our Git infrastructure
Hello, On Wednesday 24 December 2014 00:20:18 Ben Cooksley wrote: Before we go ahead and jump to a new platform though - we need to know what we want. Can everyone please suggest what they think are the things they'd like to see feature wise? Review wise, I'd like to be able to review full patch queues. Right now we're not dealing well with patches built on top of some other patches which makes it either painful for the contributor working around that, or painful for the reviewer who end up reviewing several patches squashed together. I'd like to be able to comment both on the code and the commit log (currently that's just the code). I'd like a finer grained voting system. It's fine that we got everyone the ability to vote, but not all votes are born equal. There's no easy way for people to know if a ship it is from a maintainer or someone less confident about the code base. I'd like to be able to apply a patch straight from the review interface. Otherwise there's always this akward situation for patches where you validate them and then the person disappear for a while, the patch being applied much later if applied at all. Contribution wise, I'd like a simple command line client which allows me to take my local patch queue and put everything up as separate reviews. Also if the patches were already up for reviews it should be clever and update the existing reviews not create new ones. Feels like writing a letter to Santa Claus. Good timing. ;-) Note that while Continuous Integration is something which could integrate with this infrastructure, it is something which is not being re-evaluated at this time. Any attempt to include it within this discussion is considered off topic and out of scope. Fair enough. That said if we're talking about selecting a tool it's not completely transparent either. Some tools are better suited at running the CI before a patch gets in, doesn't seem to be the case with our current stack. My point here is: whatever the change, we ought to make sure it's not tying our hands in the CI department. Knowing the outcome of the CI is important to me when I review. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Using Gerrit for code review in KDE
On Tuesday 09 September 2014 20:02:55 Aaron J. Seigo wrote: In any case, can you see the inconsistency between saying we need highly active repos to find pain points and these projects will only use it on an opt-in basis, and not even for all patches? You may as well throw a more lightly developed repository at it all-in to get that same level of activity. Either that or kio and plasma-framework will go all-in and then it is exactly like the gitlab experiment. You really can't argue it both ways. OK, let me put it differently I would expect (I obviously don't control them though) the core contributors of those two frameworks to go all in for a while. Where I see a difference is that during the time of experiment it will leave the other less committed contributors undisturbed. A reasonable project of a 3-5 active developers who are doing 2-3 patch sets a week ought to give one all the data set necessary. One can extrapolate from such a sample pretty easily. I know I managed to do it with gitlab and there wasn't even that level of activity. I agree that makes sense too. Now there was a will in the room of trying out with a couple of frameworks. Right now we seem to be in a phase active vs almost inactive, so people chose two active ones. So as I asked, are there any actively developed repos that aren't *as* critical and part of major stable releases? That ought to be a rhetorical question as I can think of probably half a dozen off the top of my head. How about that new video player that was demo'd at akademy? How about kde-connect? How about the plasma-desktop repository, if the plasma team really wants to try it out? Sure, all valid ones to try with IMO. Why go straight for stable, releasing frameworks? Basically the topic was brought up to that particular BoF by Jan which in turn prompted the OK, this installation is low risk, let's try with two frameworks to test the water. Part of the reasoning there has also been the tool might give us further ideas on our branch policies, since there's some KF specific decisions around those due to the one month cycle it was considered to make sense to have KF part of the experiment. I then doubt it would be a problem for new developers. The only thing they would loose by default is the knowledge of some of the patches cooking up in Gerrit when the team tests it. But I would be surprised if the majority of new developers actively look at the list of patches prepared in RB either. I'd think about the will-be-long-term-active minority for which one ought to keep the barrier to entry low which includes consistency in tooling Agreed, but that's where I don't follow you. Those one shouldn't see a difference in the barrier of entry during the experiment. and a reasonable measure of project-follows-documented-processes. That I can agree with that indeed for a limited time some people in the project will go through a specific review tool. That said our policies in KF ask for reviews, they don't mandate a particular tool. It was done to open the door to reviews by email and pastebin. It is no different IMO. I'd also think about the developers who follow those reviews now and who will now have to pay attention to multiple tools to keep up. Those were in the room and willing to pay that price for the time of the experiment. I'm all for improvements through change, but one can minimize disruptions as they go. Sure. Still I fail to perceive a large disruption in that case. I'd agree if we said OK, all contributions to kio go through Gerrit now, we're saying during the time of the experiment core devel contributions to kio go through Gerrit, everything else is business as usual. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Retiring and testament
Hello dear KDE contributors, I'm sending this from Akademy 2014. Our KDE Frameworks BoF is now over, as usual we did great progress: https://community.kde.org/Frameworks/Meetings/201409Akademy Also I put in place the goals for the months to come before coming: https://community.kde.org/Frameworks/Epics It might require updating based on the minutes of the meeting. Now, let's get to the subject of this email: effective immediately I will be stepping back from KDE Frameworks to refocus my energy elsewhere in KDE. Some of you probably saw this coming as I was already less active over the past few weeks. I have been working on kdelibs (and now KDE Frameworks) related topics almost since the beginning of my involvement in KDE. I came to realize that I needed to do different things now. After ten years, and although I love the project, I just don't have enough energy to keep going on my spare time. You will still see me around of course. I'm retiring from KDE Frameworks, not from KDE. I just want to focus mainly on Zanshin and some of my community work (french promo, manifesto, e.V.). Because of my other involvements you'll probably see me sending patches from time to time to KF5, just don't expect me to monitor closely what's going on or to drive anything anymore. Also, I am actively discussing with Kevin Krammer to pass him the torch. I guess most of you know him. He will be a good replacement since he has a good view on the whole stack. Not to neglect the fact we both have the same first name so you feel right at home. :-) I'm a bit emotional of letting that go of course, but I'm retiring from KDE Frameworks knowing our community brought it in a very good place. It made the leap to a completely new arena which opens plenty of opportunities. If we want to reap the fruits I'd like to see the following things happen in the next few months: * kdepimlibs and akonadi fully transitioned to KF5 (latest in early 2015, our application ecosystem need it to strive in the KF5 world); * a clear developer story for third parties wanting to use parts of KF5 (they are one of the main motive for the modularization, it should be easy for them to use the result of our efforts); * a stronger take on quality, especially more tooling support on reviews and tests even on non-Linux systems (we're still dropping the ball often I think, our craft needs to be perfected); * a very good documentation (the apidox and book are an amazing start already!); * the closing of k-f-d in favor of k-c-d again (see kde-community for the reasons); * emails from reviewboard on a list similar to kde-commits and not on regular mailing lists anymore (this constant noise prevents higher level thinking on our lists IMHO); * more reaching out to qt-interest (making it easy to use KF5 for third parties is nice... making them aware of it is even better). Take the points above as my testament. I believe they are essential for the broader success of KF5 and ultimately for the success of our community. I hope that in your capable hands I will see those wishes fulfilled. Keep having fun with our collective creation! And don't hesitate to still send me direct emails if you're in need of an extra opinion or advice, I'll always have some time to answer my fellow gearheads. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Using Gerrit for code review in KDE
Hello, OK, I guess there might be some misunderstanding or at least partial information due to live meeting vs short announcement on list. On Tuesday 09 September 2014 17:39:54 Aaron J. Seigo wrote: On Tuesday, September 9, 2014 16.59:35 Jan Kundrát wrote: On Tuesday, 9 September 2014 16:44:22 CEST, Eike Hein wrote: Exclusively, or do they remain on ReviewBoard as well? My understanding is that they do remain on RB as well for now. The goal of this excercise is to get some understanding on how Gerrit works and whether it's a good match for frameworks; we aren't imposing some wide-ranging changes. Would it not make more sense to trial it using newer / smaller / unstable projects, as it is an experiment? People at the meeting picked those two because it was deemed desirable to avoid using something small or not too active to find the pain points. I think it makes sense. For something which seldom get patches it's unlikely we'll have enough information for later decision. As it stands with plasma-framework in particular, there is now a difference in workflow depending on what *part* of plasma one is working on (framework or workspace). So not only is it now different from the majority of frameworks, it is also different from itself. It was focused on KF5, but if Plasma people feel like having all the related repositories part of the experiment they could decide it but... That this doesn't follow current documentation (such as it is) for new developers certainly can't help any. ... the experiment is not about Gerrit vs Gitolite + ReviewBoard. It is Gerrit in addition to Gitolite + ReviewBoard. In that sense it is very different from the earlier GitLab experiment. Also it is completely opt-in for developers when they submit patches. I then doubt it would be a problem for new developers. The only thing they would loose by default is the knowledge of some of the patches cooking up in Gerrit when the team tests it. But I would be surprised if the majority of new developers actively look at the list of patches prepared in RB either. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Solid BoF at Akademy
Hello, On Wednesday 13 August 2014 12:15:18 Jan Grulich wrote: I would like to inform that we decided to arrange a Solid BoF at Akademy on Tuesday in the second room after lunch. If you are interested in Solid stuff, including Plasma Networkmanagement, KScreen, Powerdevil, Bluedevil etc. you are free to join us!! Wouldn't that be a problem to have that in parallel with the KDE Frameworks BoF? There's a solid module in KF5. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: code guideline
On Wednesday 09 July 2014 10:15:03 David Faure wrote: On Saturday 28 June 2014 08:51:42 Rodrigo Bonifacio wrote: Dear all, is there any code guideline that recommends developers to avoid the use of exception handling mechanisms within the core libraries of KDE? I don't think it's written down anywhere, but yes, please do avoid the use of exception handling. I hate debugging uncaught exceptions, no way to get a backtrace of where the exception was thrown. Isn't catch throw in gdb just for that? I regularly use it when I've to deal with exceptions. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w28
Hello everyone, This is the minutes of the Week 28 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: agateau, apol, d_ed, dfaure, fregl, mgraesslin, notmart, PovAddict, Riddell, sandsmark, tosky, unormal, vHanda and myself. Announcements: * KF 5.0 got officially released yesterday! * As announced this meeting is more forward looking than reporting, especially useful would be: features you want to see appear, and areas for improvements you see; * It will be our last regular meeting for the time being, we can move to flow base without trying to set a strict deadline now (as release and development is mostly decoupled); * agateau would like to see the ColumnResizer class get out of review limbo (probably didn't have enough energy to get it in Qt, would happily push it to kwidgetsaddons); * apol would like us to figure out how we expect people to develop on apps with KF5; * we need to ensure the tooling is there and that it's easy to get started; * he's also like to see the android port progress, in particular he got no answer about getting a file in ECM to that effect; * d_ed has two models he wants to get into kf5 at some point (one similar to KCategoryModel, allowing a row in two categories, the other one merges two list models together); * also he'd like the framework integration to be cleaned up and to sync itself with breeze's settings; * dfaure plans to complete the startup notification in kdbusservice; * he also plans to replace sycoca; * he also wants to figure out what to do with libkonq; * fregl wants to see more focus on a11y; * he notes it will require being able to operate plasma based code with the keyboard; * mgraesslin would like windows and macos support effective in KWindowSystem; * he plans wayland support in kwindowsystem too; * he'd also like the runtime component of kglobalaccel back in the framework itself; * notmart would welcome a git hook to make sure all commits are reviewed; * he's not sold on the no branches policy, actually plasma-framework seeing heavy work he pushed feature branches already (said policy isn't written anywhere BTW); * for the upcoming versions he wants the runtime part of plasma-framework to converge as much as possible the plasma components and the qt controls; * there's interest to move Package out of plasma-framework, a solution should be devised; * PovAddict is working on a single-app installer for windows: http://i.imgur.com/zokLHVe.png ; * he'd like our documentation to improve, we're really behind alternatives in that regard; * Riddell would like kauth/polkit fixed; * he'd like the kwallet migrator done ASAP; * he'd also like kdesudo next to kdesu; * finally, he pointed out that the schedule was missing the string freezes; * sandsmark wants to get to grammar checking in sonnet; * he's also like to get auto-correct in sonnet; * tosky would like to see more tests; * he'd also want more work on some of the i18n components; * unormal is looking forward to more mac CI results; * the windows CI is a bit stuck; * he'd like to see progress on the android CI; * he'd like to see a donation button in KDE apps based on KF5 (developers could opt-out); * he's thinking we should ask third party developers if they want to send us some information when they use a framework to create an app; * vHanda would like kfilemetadata to make it into a framework; * he'd also like to turn baloo into a framework; * finally he'd like gestures in kglobalaccel; * ervin hopes to see kdepimlibs bits getting in sooner rather than later; * also he would like our developer story to be clearer, tooling needs to be improved for our different targets (especially third parties); * finally he thinks we need to strengthen our CI system and tests to raise the bar on quality. If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KF5 Update Meeting Minutes 2014-w28
On Tuesday 08 July 2014 18:27:52 John Layt wrote: Here's a bit of bike-shedding for you: when creating completely new Frameworks in Tier 1, do we name them with a Q or with a K or with something completely neutral? Not really a bike-shedding topic hopefully... We had the case already and we used K. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KF5 Update Meeting Minutes 2014-w28
Hello, On Wednesday 09 July 2014 09:57:27 Ben Cooksley wrote: On 9 July 2014 03:30, Kevin Ottens er...@kde.org wrote: * ervin hopes to see kdepimlibs bits getting in sooner rather than later; Hmm? Sysadmin has already received a request to get the frameworks branch of kdepimlibs building on the CI system to allow for KMyMoney's frameworks branch to be built. I thought this was already underway? There's work underway of course. Laurent is very instrumental there. But there's still a long way to go AFAIK. Having a branch that builds is a first step, but then splitting the repository will be necessary, figuring out which parts of kdepim-runtime will go with which part of kdepimlibs, organizing the splitted repositories so that they follow the existing policies, etc. It's pretty much the kdelibs/kde-runtime work again, it shouldn't be underestimated. * also he would like our developer story to be clearer, tooling needs to be improved for our different targets (especially third parties); * finally he thinks we need to strengthen our CI system and tests to raise the bar on quality. Expand on strengthen please? Sure, for the CI side what I have in mind is mostly about supporting more platforms (at least windows, mac and android as mentioned earlier) with all the results in the same dashboard (currently the mac results come from somewhere). For the tests side, it is about getting way more tests introduced, we might also want to start looking at the coverage data (although the CI might be the bottleneck there). Hope that clarifies. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w25
Hello everyone, This is the minutes of the Week 25 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: agateau, apol, mgraesslin and myself. * agateau did some kapidox fixes on api.kde.org; * he also fixed a crash in KCMultiDialog; * he also proposed ColumnResizer for QtWidgets, KWidgetsAddons as contingency plan; * apol communicated on how to build kalgebra on android, which shows it is a platform we can support for KF5: http://www.proli.net/2014/06/12/kde-software-on-android/ ; * he would like to discuss if it would make sense to move AndroidToolChain.cmake to ECM; * mgraesslin reports that Qt 5.3.1 will have the xcb_flush patch and so our workaround can be disabled; * he also doesn't really know how the default shortcuts should behave in kglobalaccel compared to setShortcut: https://git.reviewboard.kde.org/r/118783/ ; * ervin has been away past few weeks, slowly getting back in business. If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w20
Hello everyone, This is the minutes of the Week 20 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, alexmerry, arichardson, PovAddict, Riddell, sebas, shadeslayer, teo and myself. * afiestas has been working on the async powermanagement API (for now disabled during build, need to force the WITH_NEW_SOLID_JOB and WITH_NEW_POWER_ASYNC_API options to get it built); * he'll push backends and request API review; * agateau produced the framework list on api.kde.org with jquery bling included; * he also did fixes to ki18n and kdoctools macros; * he finished the l10n related task (woohoo!); * he's waiting on a couple of review: https://git.reviewboard.kde.org/r/117954/ https://git.reviewboard.kde.org/r/118114/ ; * arichardson is trying to get the unit tests running on windows; * he also fixed kurifilter-plugins unit tests; * PovAddict has been helping arichardson with the unit tests; * he also fixed a few frameworks using C++11 features MSVC2010 doesn't have; * he notes there's a worrying number of frameworks with no or few tests; * Riddell reports that kubuntu packages are all done and looking nice; * exception is kauth because of polkit-qt; * no networkmanage release as wanted by kdelibs4support; * sebas is working on locale and translation settings with jlayt; * shadeslayer fixed the ssl kcm, and found more issues in the kio ssl: https://git.reviewboard.kde.org/r/118102/ https://git.reviewboard.kde.org/r/118104/ ; * he also plans to fix the deprecated warnings in kio; * teo fixed some local issues he had with kwalletd5 on demand start; * he's also working on fixes for the kwallet kcm; * he found that KPasswordDialog looks bad on hidpi display; * ervin took credit of other people work at FISL15; * otherwise he did mostly reviews; * alexmerry has been mostly making sure that plugins are versioned for a kf6; * he also moved kurifilter plugins to kio; * and he has a patch for KDEInstallDirs that adds variable names in keeping with GNUInstallDirs. If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KDE Frameworks: There will be a beta 3
Hello all, After the release of beta 2, we realized that it couldn't be the last beta for several reasons: * a long standing release blocker in libsolid still wasn't addressed in time for beta 2, it'll hopefully be solved in the next few days, otherwise we'll put in place a contingency plan; * the paint is still a bit fresh on some of the internationalization work after the sprint and it could benefit from some more testing; * some quirks were still found in the release scripts, so having an extra run before final can't hurt to check all the pieces fit together now. That's why on early June we'll release a beta 3. In turn, the final is now due to be out on early July (one month later than expected). Thanks for your attention. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w18
Hello everyone, This is the minutes of the Week 18 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, apol, dfaure, notmart, PovAddict, Riddell, shadeslayer, tosky, teo, vHanda and myself Announcement: * Beta 2 to be tagged end of this week! Please finish the last release blockers before that, to give us a full month of testing and bug fixing. * agateau attended the sprint and worked on translations there; * he has a review request to provide a simple way to add the cmake code to install translations from release tarballs; * he also resumed working on kapidox (he got a generated list of frameworks on the frontpage, can be filtered by platforms); * apol did some of the splitting tasks that were left during the sprint; * he also worked on the KDEInstallDirs refactoring to make sure everything is in the correct location when installing; * dfaure worked on a bunch of stuff at the sprint, his memory is blurry... something about the release scripts (was he drunk??); ;-) * he's hopefully ready for releasing beta 2 on sunday; * notmart has got plasma-framework imported into frameworks at last; * it triggered an issue with a duplicated class, but that's solved; * he created the framework-plasma product on bugs.kde.org; * PovAddict is investigating a ktexteditor crash on windows; * Riddell kept working on coinstallability issues: https://git.reviewboard.kde.org/r/117148/ https://git.reviewboard.kde.org/r/117150/ https://git.reviewboard.kde.org/r/117864/ https://git.reviewboard.kde.org/r/117858/ * tosky is a bit late with the final kdoctools fixes for translations of docbooks; * he also pointed out that thanks to tsdgeos and blueck the translation infrastructure for kf5 is going to work soon; * teo is back on kwallermanager, fixing some last things; * he didn't port kwalletd but the tests pass; * vHanda took over maintainership of krunner; * ervin has been attending the sprint, helped with tasks there; * he is also preparing for the FISL talk next week, almost there; * last but not least he announced the post 5.0 plans; * shadeslayer is looking into an automated ABI checker tool for KF5; * afiestas worked with kai on the solid qml API, it is up for review; * he'll also put up for review the new Solid::PowerManagement API this week; * last but not least he ported kscreen and prepares it for making it a framework someday. If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Maintainers: Please get ready for release
Hello framework maintainers, As you know we're getting near the final release. If we don't hit a critical issue, we'll release the final early June. Before that, we'll have a second beta on May 4th, and we'd like it to look as close to the final as possible. That's why I'm sending you this email. Please take time in the coming week to look at your frameworks and do that last bit of spring cleaning. I propose you the following checklist (you can add more steps if you feel like, but I consider that the minimal checklist): * Have you reviewed the metainfo.yaml file of your frameworks to make sure the information it contains is accurate and up to date? * Have you checked that your frameworks followed all the steps in the creation guidelines? (especially bugzilla component, reviewboard, etc.) http://community.kde.org/Frameworks/CreationGuidelines * Have you checked that your frameworks are compliant to the policies in place? http://community.kde.org/Frameworks/Policies * Have you done the necessary for your frameworks to be green on the CI? http://build.kde.org/view/Frameworks/ * Have you done a last pass of review of your APIs for source compatible improvements? Please get back to us when you're done checking your framework, if you get any issue or if something is unclear. For information, here is the list of maintainers and the frameworks they maintain. You'll also find the list of frameworks with no maintainers at the end of the list. It would be nice to see more people step up to maintain frameworks, or give a hand applying the checklist above to frameworks without maintainers. Alex Merry: - kdesignerplugin - kimageformats - kmediaplayer (porting aid) Aurélien Gâteau: - kapidox Bernd Buschinski: - kjs (porting aid) - kjsembed (porting aid) Christoph Cullmann: - ktexteditor Christoph Feck: - kiconthemes - kplotting - kwidgetsaddons Chusslove Illich: - ki18n David Edmundson: - kitemviews - knotifyconfig David Faure: - karchive - kcrash - kdbusaddons - kinit - kio - kparts - kservice David Gil Oliva: - kcompletion Ivan Čukić: - kactivities Jeremy Whiting: - knewstuff John Layt: - kunitconversion Laurent Montel: - ktextwidgets Luigi Toscano: - kdoctools Marco Martin: - kdeclarative - plasma-framework Martin Gräßlin: - kglobalaccel - kwindowsystem Martin Klapetek: - knotifications Martin Tobias Holmedahl Sandsmark: - khtml (porting aid) - sonnet Matthew Dawson: - kconfig - kdnssd Michael Pyne: - kcoreaddons Mirko Boehm: - threadweaver Valentin Rusu: - kwallet Àlex Fiestas: - frameworkintegration - kded - solid No maintainer: - attica - kauth - kbookmarks - kcmutils - kcodecs - kconfigwidgets - kdelibs4support (porting aid) - kdesu - kdewebkit - kemoticons - kfileaudiopreview (porting aid) - kguiaddons - kidletime - kitemmodels - kjobwidgets - kpty - kross (porting aid) - krunner (porting aid) - kxmlgui Let's get ready for a great 5.0 release! Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KDE Frameworks Release Cycle
Hello people, As you may have noticed, we're covering quite a few tasks here during the sprint. But, we're also having discussion topics, and the most important one we covered is the release cycle. Indeed, we got the question several times already of once 5.0 is out what will happen? It is what I'll try to address in this email. Short story: we'll go for a one month release cycle, with no branch. You can stop reading here, thank you, bye! ... Still here? Oh you want more details!? OK, read on. :-) So, we had a team discussion here with Albert, Aleix, Alex, Alex, Aurélien, David, Rohan and myself. We juggled with several options, trying to address the following constraints: * We don't have many contributors; * We don't have enough testing in the stable branches, developers tend to have a hard time to dog food those; * We don't have enough contributions coming from the application developers because it takes a lot of time for them to benefit from their changes so they tend to workaround instead and consider kdelibs more and more as a black box; going forward we don't want that for KDE Frameworks. We ended up settling on the one month cycle, no branch option because we think it should address the constraints above. In a more detailed way here is what we mean by one month cycle, no branch: * Everything is developed in master, so each release will contain a few new features and bugfixes; * The only freeze will be a message and docbook freeze, it will happen for the last two weeks prior to release (so we'll be in message/docbook freeze 50% of the time); * Releases will materialize in the form of a tag and a tarball; * We tag the release at the beginning of each month, as close as possible to the first day of that month; * Unlike previously, tags will be pushed immediately, we'll first tag a rc1 and produce the tarballs, if no issue is found by packagers in a week then it will be retagged as final, if issues are found we'll tag a rc2, etc. Currently David will be the one producing the releases. He'll announce the exact dates for the freeze and release of the current cycle during the first 10 days of the cycle since that's partly based on his own availability. Of course, going with this type of cycle comes with some price of its own: * Features in released modules can only be introduced in a very fine grained way so as to not jeopardize the stability; * CI should be always green, breakages should be treated as stop the line events (all commits following a breakage should only be to try to get things back to normal); * There should be a strong focus on automated tests and peer review: all modified code should come with corresponding tests; if you got a framework which is low on test coverage because of its architecture it's likely time to focus on the tooling and test harnessing. Thanks for your attention. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w16
Hello everyone, This is the minutes of the Week 16 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, alexmerry, apol, notmart, tosky and myself Announcement: * I won't be around next week for the meeting, Riddell will run the one next week; * afiestas pushed all the changes he aimed at for solid; * he's going to move some runtime bits to kdelibs4support; * he also plan to have the new async powermanagement API on review soon; * agateau worked on translation support; * he also proposed changes to ECM for handling .qm files; * and there's been back and forth on how to handle qt based translations; * alexmerry worked on ECM online docs (thanks to winterz for getting them on api.kde.org); * he's almost done with the kde4 reference task; * he also completed the renaming from kde4support to kdelibs4support; * apol finished splitting important parts from kde-runtime; * he plans to finish on the documentation and l10n; * he'd also need someone to look at https://git.reviewboard.kde.org/r/117565/ ; * notmart fixed bugs in kxmlgui and kwidgetsaddons * tosky helped with translations on kf5; * he's still investigating but almost done with the remaining issue in kdoctools; * he'll also investigate why khelpcenter doesn't show anything; * ervin has been mostly sick, reviewing and annoying on list (in no particular order). If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Default bugzilla asignees for frameworks
On Tuesday 15 April 2014 17:07:38 Martin Klapetek wrote: Hey, As we now have people stepping up as frameworks maintainers, I think part of that maintainership should be becoming the default assignee for given framework on bugzilla. For example I filed a bug against KIO and that was assigned to kdelibs-b...@kde.org, where I imagine it gets drowned among other kdelibs bugs. Given we're going big with frameworks now, we /need to/ make our bug handling better than sending them to kdelibs-bugs. If there are no objections, I'll assign frameworks bugs to people as per the table here: https://community.kde.org/Frameworks/List Please do so. It's indeed maintainer's duty. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w15
Hello everyone, This is the minutes of the Week 15 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: agateau, apol, mck182, notmart, tosky and myself. * agateau put more work on translation support for Qt-based frameworks; * he fixed string extraction from .ui files; * he's also working on setting up scripty to work with .qm files; * he's also trying to figure out the best way to handle plural forms since Qt differs a lots from ki18n there; * alemerry is almost done with the KDE4 reference removals; * he also upstreamed find module docs to CMake; * apol has been working on moving kde-runtime components in their final positions; * mck182 has been working on fixing QFileDialog::getExistingDirectory in our plugin: https://git.reviewboard.kde.org/r/117435/ * notmart moved plasma-shell out of plasma-framework and into plasma- workspace (making plasma-framework strictly library and plugins); * tosky is working on kdoctool still; * he's also working on KDE4 references; * he still plan to address a few bugs in the next days; * ervin has been mostly reviewing. If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w14
Hello everyone, This is the minutes of the Week 14 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, alexmerry, apol, notmart, Riddell, tosky and myself. * afiestas will push the branch with removed interfaces; * he's first making sure no breakage will happen anywhere and will also put some bits in kde4support; * he'll then add async APIs for a couple of classes; * agateau has been working on translation support for tr based frameworks; * he created new script for l10n-kde4 and added Messages.sh scripts where missing; * he also added ecm_create_qm_from_po_files; * alexmerry got the SIC changes he wanted in before beta 1... but found more; * he's still working on removing the kde4 references although at a slower pace; * apol has been moving kde-runtime bits in several frameworks; * he should be all done by the end of this week; * notmart renamed qtextracomponents to kquickcontrolsaddons and adjusted its users; * Riddell still has to sort out the entry.desktop files; * he also got a volunteer working on the kf5options and qtoptions manpages; * he did some co-installing patches, more to come; * tosky is still working on kdoctools; * ervin has been mostly reviewing. If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w13
Hello everyone, This is the minutes of the Week 13 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, alexmerry, apol, arichardson, mgraesslin, notmart, PovAddict, tosky and myself. Announcement: * Beta1 will be tagged on Friday (so no big code moves in frameworks or SIC will be allowed after friday); * Some people will work on runtime splitting now, so please make sure everything in this list is correct: http://community.kde.org/Frameworks/Epics/New_Runtime_Organization * afiestas plans to remove some interfaces from solid before friday; * he's also working on kde-runtime splitting (see announcement above, please review the list); * agateau has worked on kf5 l10n support; * he posted a patch for ECM to support qt translations: https://git.reviewboard.kde.org/r/117052/ ; * he also posted matching changes for l10n-kde4 on the kde-i18n-doc list; * he submitted a patch to doxygen to get rid of the related pages, waiting on new doxygen release; * alexmerry worked on the kde4 references cleanup task, he found more than expected and help is *urgently* welcome: http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation/KDE4_References * he also removed some kde3 stuff and did some kservice/kded/kdeinit fixes; * he also points out a bunch of KDE5 TODOs related to API that should be looked at before friday or discarded; * apol made sure kde-runtime is building now and will work on the splitting; * he urges everyone to look at the frameworks related runtime bits; * he also did some reviews; * arichardson posted patches to fix kcoreaddons unit tests; * he also has to figure out if we want to support platform without getgrouplist(); * last but not least he's about to post patches to get kio compiling on windows (at which point everything except kde4support should work on windows); * mgraesslin removed some unused feature from kwindowsystem; * notmart moved the imports in kdeclarative; * tosky discovered an issue in kdoctools preventing kio_help use thanks to Burkhard's feedback: http://mail.kde.org/pipermail/kde-doc-english/2014-March/010464.html ; * he also got a pending patch for kdoctools on windows: https://git.reviewboard.kde.org/r/117011/ ; * PovAddict implemented KUser::faceIconPath on windows; * he also has some pending windows build fixes; * ervin has been mostly reviewing. If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w12
Hello everyone, This is the minutes of the Week 12 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, alexmerry, apol, dfaure, mck182, mgraesslin, notmart, PovAddict, Riddell, svuorela, tosky and myself. * afiestas reminds everybody to read the sprint emails he sent and update data; * alexmerry has been working on removing kde4 references in the code and it's going well; * he found a name for the default emoticons theme; * he also reimplemented the proctitle stuff in kinit for licensing reasons; * agateau started working on the l10n support in the frameworks; * he's in need of feedback for handling the tr() based frameworks; * he also did minor adjustments to kapidox; * apol is thinking about having libksysguard as a framework; * dfaure is working on updating lxr and moving it to a new server; * he's also working on KConfig API improvements and to regude the amount of file loading/parsing; * mck182 fixed a bug in QScreen/XCB so that availableGeometry() works properly; * notmart is looking into moving QML plugins into frameworks, email and reviews to come; * PovAddict figured out how to implement KUser::faceIcon on windows; * svuorela is trying to remove some hacks in ECM for windows support; * Riddell reports that 4.97.0 is all packaged for kubuntu; * tosky has finished the docbook 4.5 migration; * he also emailed kde-i18n-doc to organize kf5-based translations; * mgraesslin merged his outstanding kwindowsystem patches; * he also plans further cleanups; * ervin has been mostly reviewing; * he's also looking in how to deal with deprecated modules. If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w11
Hello everyone, This is the minutes of the Week 10 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, alexmerry, dfaure, mgraesslin, notmart, sebas, teo, tosky and myself. Announcement: * Beta 1 will be tagged on March 28 instead of April 1st as planned earlier; * Two tasks up for adoption on http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation * Please nail them down before they turn into release blockers! * afiestas has been fixing things around; * he's also working with apol on the kde-runtime split; * agateau has been doing mainly build fixes downstream; * he's also been working on some of the cmake files and on api.kde.org; * he then fixed a bug in Doxygen waiting for review; * last but not least he moved the doc policy to community.kde.org; * alexmerry is waiting for the maintainers of kdnssd before proceeding with the rename, timeout on friday; * he's also tracking bugs in kimageformats showing up on non-x86_64 architectures; * he also proposed ECMFindModuleHelpers macros for ECM and investigates on how to generate docs; * dfaure is optimizing KConfig to minimize reparsing; * he also plans to improve the KUrl - QUrl porting scripts; * mgraesslin has two open review requests for KWindowSystem which will be merged after Plasma Next Alpha tagging; * notmart is also waiting for Plasma Next Alpha tagging to move QML imports in their respective frameworks; * sebas is working on kglobalaccel; * he also has a pending patch to make oxygen the default font; * teo ported kwalletmanager to KF5; * he still has to port away from kde4support; * tosky is fixing the fallout of doctools version bump; * he still has one pending review, still open because it waits on windows or mac savvy people feedback: https://git.reviewboard.kde.org/r/116670/ ; * he also plans to remove all htdig references from kdoctools and khelpcenter; * ervin has been in review frenzy mode; If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KF5 Update Meeting Minutes 2014-w10
Hello, On Thursday 06 March 2014 02:13:36 Valentin Rusu wrote: Catching up with KF5 progress... On Tuesday, March 04, 2014 04:59:58 PM Kevin Ottens wrote: * Repository merges for kwallet and kdnssd still reported as pending... What's that? Is that about merging 4.xx repository with the KF5 one? No, the repository merge which already happened. Somehow no one closed the task, but it's done now. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w9
Hello everyone, This is the minutes of the Week 9 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: alexmerry, dfaure, krake, mgraesslin, teo, tosky and myself. Announcement: * Alpha 2 will be prepared on saturday; * Please push toward completion of the still in progress tasks, we're drifting away putting the release at risk: http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation ; * For instance, the merge of the kdnssd repos is still not done, while it's a large change we'd want in alpha 2! * alexmerry is putting e-c-m in shape for release; * there's more to do but he wouldn't feel bad releasing 1.0 as is; * he'd like more comments on http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/011667.html ; * he's also fixed a history screw up in kdoctools last chance to complain: http://lists.kde.org/?l=kde-frameworks-develm=139325409324248w=3 ; * dfaure posted review requests for KConfig waiting for its maintainer to react (added in CC); * krake ported ki18n to qtscript which makes it tier 1 (and kunitconversion tier2, etc.); * mgraesslin worked a bit on e-c-m; * he created FindEGL and FindWayland modules; * he also improved FindXCB thanks to alexmerry new documentation; * teo is still working on kwallet compatibility in ksecretservices; * he noted that kwallet.cpp is a huge mess of ifdefs with partial ksecrets support; * tosky is waiting feedback on http://lists.kde.org/?l=kde-frameworks-develm=139308438015018w=3 ; * ervin helped with reviews, reviewed everything from last week; * he also worried about the lack of progress on the release prep epic, which led to discussions with dfaure and alexmerry to drop some of the tasks; If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Changing the KDE Edu module maintainer
Hello, On Thursday 20 February 2014 15:25:22 Anne-Marie Mahfouf wrote: Best regards to all and thanks to everyone for what you brought me so far. Well, thanks to *you* for what you brought to everyone in the community so far. And of course, feel free to stop by any of the Toulouse Hacking Sessions, even if that's just to say hi for a couple of minutes. You're always welcome! :-) Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Review Request 115695: Rework KNotification to work without KNotify daemon
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115695/#review50447 --- Way to big to properly review to be honest. That said, I agree with Aleix I'd like it to be closer to the target with less regressions before letting it in. You still have a few days. ;-) Also don't forget to update the yaml and the list of frameworks in the wiki, it's moving in tier 3 territory AFAICT. - Kevin Ottens On Feb. 13, 2014, 10:14 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115695/ --- (Updated Feb. 13, 2014, 10:14 a.m.) Review request for kde-workspace, KDE Frameworks, Plasma, and Sune Vuorela. Repository: knotifications Description --- This patch merges KNotify daemon into KNotificationManager to have less daemons running and less dbus traffic. The patch is not yet finished (and for now it's full of QDebugs, that will all be removed and FIXMEs to indicate what needs doing), but as the Alpha2 is quite soon, I'd like to start the general review asap so some more changes can be done if needed. Now it's KNotificationManager that handles the KNotifyPlugin-s and hands them the notification directly. KNotifyConfig was repurposed a bit, now it serves mostly just as the .notifyrc wrapper, all the rest is reused from the KNotification object. There are some changes in the KNotification API - id() and appName() are now exposed to public and slotReceivedId(int) is now also public so that KNotificationManager can directly give it an id. I'd like to rename this and make it a non-slot. It's not the DBus/Galago server ID anymore, that is handled in NotifyByPopup which is responsible for communicating with the galago server (all the methods there were renamed to actually have *galago* in the name so it's clear), therefore the mapping of DBus/Galago Server ids is managed only there as it is actually only needed here. KNotitification::id() is assigned by the KNotificationManager and it's a simple increasing counter. The UI/Plasmoid changes will come next - basically the plan is to put only the Persistent notifications in the notifications history. Diffs - src/knotifyconfig.h PRE-CREATION src/knotifyconfig.cpp PRE-CREATION src/knotifyplugin.h PRE-CREATION src/knotifyplugin.cpp PRE-CREATION src/notifybypopup.h PRE-CREATION src/notifybypopup.cpp PRE-CREATION src/notifybypopupgrowl.h PRE-CREATION src/notifybypopupgrowl.cpp PRE-CREATION CMakeLists.txt 63ebf71 src/CMakeLists.txt a81b913 src/knotification.h 00554ba src/knotification.cpp 5d7405b src/knotificationmanager.cpp a4d0dfa src/knotificationmanager_p.h 81d962d Diff: https://git.reviewboard.kde.org/r/115695/diff/ Testing --- Works perfectly with both plasma notifications and kpassivepopup. Thanks, Martin Klapetek
KF5 Update Meeting Minutes 2014-w7
Hello everyone, This is the minutes of the Week 6 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, alexmerry, apol, dfaure, dgilo, krake, mgraesslin, Riddell, teo, tosky and myself. Announcement: * Alpha 1 still not published; * Please make sure if you got some tasks that it's status is up to date: http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation (especially relevant for agateau, alexmerry and valir); * We need to push toward completion for the in progress tasks; * afiestas got greenlight from valir to push his first patch into kwallet; * he'll also ask for reviews on the pam module; * he's going to discuss the kwallet vs ksecretservices plans with teo and valir; * agateau is done with the README files; * he also wrote the framework documentation policy; * he's almost done with having the dependency diagrams on api.kde.org; * alexmerry is moving some kimgio stuff into Qt but will miss the 5.3 freeze; * he also did a bit of reviewing, he has a few requests waiting; * he'd like to see more people browsing though the kdeframeworks group on reviewboard (very important job); * apol split krunner from plasma-framework; * he's also been working on kde-runtime splitting to the mix; * dfaure packed up alpha 1; * he also added kactivities and plasma-framework; * the packagers reported success except for plasma-framework (investigation in progress); * krake succeeded in porting ki18n to QtScript which will make it tier 1 once the patch is in; * mgraesslin made sure kwindowsystem builds without x11; * thanks to our awesome sysadmins we have a build variation for that case; * he's also testing apps over wayland and fixing problems as he finds them; * he also fixed Qt for 5.3 so that the wayland platform backend uses our platform theme; * Riddell has to discuss entry.desktop in language packs with l10n people; * he's also rewriting the kdeoptions man page; * teo found out that ksecretsservice needs some love; * he also ported it to kf5; * tosky delayed some of his changes because of alpha 1 unclear status; * dgilo is cleaning up kcompletion, two reviews pending. If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w4
Hello everyone, This is the minutes of the Week 3 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, alexmerry, arichardson, dfaure, mgraesslin, Riddell, tosky and myself. Announcement: * Come on people, we're still short on maintainers! * Aiming at a frameworks sprint somewhen in spring; * Don't forget that Alpha 1 is due for release next week; * afiestas signed up for maintaining kded; * he also wrote a proposal to split runtime and workspace: http://community.kde.org/Plasma/Tokamak7/split_proposal * agateau fixed ki18n so that tests would work without install; * he also worked on integrating kf5dot in kapidox; * he also created a todo list for the doc of the frameworks and the tooling; * alexmerry got the apidox script working; * he is about to remove all the Mainpage.dox files as the script won't need them (preserving useful content of course); * he's also working with ben to get the necessary deps on ebn to run the script; * he's also working on reducing the KDE stuff in ECM; * arichardson got almost all of KF5 building on windows, patches to follow; * he got to the point where okteta is running on windows: http://postimg.org/image/51gwpoxpf ; * dfaure is focusing on generating .pri files for qmake users; * he needs a review on https://git.reviewboard.kde.org/r/115099/ ; * he also started to fix kcrash use of command line options; * mgraesslin took over maintainership of kwindowsystem and kglobalaccel; * he's working on KWindowInfo unit tests; * he also plans to transform the classes to give them runtime platform detection for wayland; * he'll need help from windows and mac people if they don't want their implementations to break; * Riddell is working on coinstallability, especially around dbus interfaces; * he's also close of having tier 2 fully packaged, some parts of tier 3 being done already; * tosky found out that the validity of the qtoptions and kdeoptions man pages is in need of review; * he's also working with the doc team toward a switch to docbook 4.2; * ervin got a few more maintainers, still some positions open; * he also contacted afiestas for a sprint in Barcelona. If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks: Looking for maintainers
Hello, I thought it'd be interesting to some to get updated stats since my last call to arms. On Monday 13 January 2014 19:40:54 Kevin Ottens wrote: This is a reminder that we're still looking for maintainers for our frameworks. Out of the 57 existing frameworks 25 have no maintainer (yes, that's almost 45%). It's still too much for my taste, but it's better than the 60% we had previously, thanks to the one who stepped up since my last call! The modules without maintainers are spread this way: - 8 are tier 1 (so depending only on Qt); - 4 are tier 2 (depending on Qt and a couple of tier 1); - 11 are tier 3 (larger dependencies) - 2 are tier 4 (kde4support and modules helping for platform integration). I'd like to thanks all the people who already stepped up to become frameworks maintainers! And for those still hiding in the dark, here is your chance at providing a very critical service to our community! If you hesitate on becoming a maintainer, feel free to get in touch with me, we can probably work together to find something where you'll feel at home. If you have a calling to become a maintainer and already have well formed tastes and responsibilities you'd like to take, head to the wiki and book one of the frameworks: http://community.kde.org/Frameworks/List Out of the ones without maintainers, the most critical to get a maintainer are the following ones: * KItemModels; * KConfig; * KGuiAddons; * KWindowSystem; * KCrash; * KDED; * XmlGui. If you feel like you should be the one maintaining some of those, seize the relevant ones on the wiki! Cheers! -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w3
Hello everyone, This is the minutes of the Week 3 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, alexmerry, dfaure, mck182, Riddell, valir and myself. Announcement: * We're *still* actively looking for maintainers! Konqi wants YOU! * afiestas signed up for maintainership of FrameworkIntegration; * he's also making sure that Plasma 2's systemsettings updates Qt4 apps; * he's also toying with the idea of using QFuture for libsolid future async API; * agateau is improving kf5dot to get the dependency graphs; * he's also working on integrating that with kapidox; * in fact he even signed up for kapidoc maintainership; * his first task will be to integrate alexmerry's work on the apidox generator; * alexmerry is now maintaining kimageformats, kdesignerplugin and kmediaplayer; * he's also rewriting the apidox script and found files in the wrong repos while doing that; * he's also waiting on a few reviews while reviewing other people submissions; * mck182 is looking into our current notifications system to prepare a replacement; * it seems doable with just small api changes in KNotification and some server changes; * Riddell got all of tier 1 packaged in Kubuntu; * he got to move some overlapping files and add some licenses files; * he got some pending reviews, more to come when he'll tackle tier 2; * dfaure has been mostly reviewing patches; * valir merged kwalletd in kwallet-framework which made it tier 3; * he'll look into making kinit optional which will make kwallet tier 2 again; * ervin is making progress finding maintainers but at very slow pace. If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KDE Frameworks: Looking for maintainers
Hello everyone, This is a reminder that we're still looking for maintainers for our frameworks. Out of the 57 existing frameworks 33 have no maintainer (yes, that's almost 60%). I don't know about you, but I find that worrying. The modules without maintainers are spread this way: - 9 are tier 1 (so depending only on Qt); - 7 are tier 2 (depending on Qt and a couple of tier 1); - 14 are tier 3 (larger dependencies) - 3 are tier 4 (kde4support and modules helping for platform integration). I'd like to thanks all the people who already stepped up to become frameworks maintainers! And for those still hiding in the dark, here is your chance at providing a very critical service to our community! If you hesitate on becoming a maintainer, feel free to get in touch with me, we can probably work together to find something where you'll feel at home. If you have a calling to become a maintainer and already have well formed tastes and responsibilities you'd like to take, head to the wiki and book one of the frameworks: http://community.kde.org/Frameworks/List Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Wednesday 08 January 2014 10:56:41 John Layt wrote: On 8 January 2014 07:17, Kevin Ottens er...@kde.org wrote: For the record, if that depends on QtPrintSupport it can't make it to KGuiAddons (which should depend only on QtCore and QtGui). Good point :-) I'm fine keeping it even if it's small. OK, I'll take the chainsaw to it this weekend and see what we're left with. Don't forget to keep SC though. Might mean properly deprecating stuff (toward kde4support for instance). Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w2
Hello everyone, This is the minutes of the Week 48 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, alexmerry, apol, d_ed, mck182, mgraesslin, Riddell, sandsmark, sebas, svuorela and myself. Announcement: * Happy new year! * TP1 is officially out, congrats everyone! * We're looking for maintainers! Konqi wants YOU! * afiestas is planning to focus on solid (async API, power management, deprecate what needs to be, more unit tests); * agateau plans to work on kapidox, integrating the diagram generation in; * he'll also resume the work on the README and accompanying files in the frameworks; * apol plans to put the headers policy in the wiki; * d_ed plans to maintain kitemviews, leaving kitemmodels to steveire; * mck182 plans to work on the notifications, probably maintaining knotifications; * mgraesslin is pondering taking the maintainership of kwindowsystem; * alexmerry has adopted svuorela cmake patch, he's waiting for a second ship it on it; * he also plans to adopt kimageformats and kmediaplayer; * Riddell is packaging TP1 and finding issues that he'll soon report; * sandsmark is about to merge his sonnet refactoring; * he also plans to forward port some patches for khtml; * sebas is working on research for knotifications; * he also plans to bugfix if things crop up; * svuorela is available for reviews and for testing ideas on; * ervin is focusing on the framework/maintainer matchmaking. If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Tuesday 07 January 2014 07:22:01 Kevin Ottens wrote: On Tuesday 07 January 2014 00:45:19 Christoph Feck wrote: On Monday 06 January 2014 23:54:46 Kevin Ottens wrote: On Monday 06 January 2014 22:26:27 Alexander Neundorf wrote: IMO something like proposing the maintainers and approving them, similar to Qt, would be good, i.e. at least some kind of voting by who we will be governed. Definitely something we'll need at some point. For bootstrapping I'm more looking for volunteers ATM, we have more seats to feel than declared candidates... If everything else fails (in other words, if we really want to have a name listed, but nobody else steps up), I am willing to maintain these frameworks: - kiconthemes - kimageformats (including webp plugin from kde-runtime) - kplotting - kwidgetsaddons You can take KIconThemes, KPlotting and KWidgetsAddons then. I'm not aware of anyone else interested in those. If you're still willing to maintain them you know where and how to put your name in front of them. ;-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KF5 Update Meeting Minutes 2014-w2
Hello, As a reminder the maintainers list is available there: http://community.kde.org/Frameworks/List People willing to maintain a framework should put their name in the corresponding column. On Tuesday 07 January 2014 16:53:30 Kevin Ottens wrote: * agateau plans to work on kapidox, [...] Aurélien: Feel free to take over the maintainer hat for that framework. You know where to put your name. :-) * d_ed plans to maintain kitemviews, leaving kitemmodels to steveire; David: Same thing, please put your name in front of KItemViews. Steve: KItemModels is all your as soon as you put your name in front in the wiki. * mck182 plans to work on the notifications, probably maintaining knotifications; MartinK: KNotifications is your if you step up for it. * mgraesslin is pondering taking the maintainership of kwindowsystem; MartinG: KWindowSystem is your if you want it, put your name. I know you're undecided because of the windows support, but I think the chat on IRC and my previous email should clear up most of the worries. If you got more feel free to get in touch. * alexmerry [...] plans to adopt kimageformats and kmediaplayer; Alex: Both KImageFormats and KMediaPlayer are your if you adjust the wiki page accordingly. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
Hello, On Tuesday 07 January 2014 18:10:10 John Layt wrote: On 6 January 2014 07:52, Kevin Ottens er...@kde.org wrote: I urge everyone, and in particular people volunteering to maintain a framework, to do a pass of review of our code base and APIs to modernize them when appropriate. It is a very big task, and in no way can be coordinated in the way we've been working so far. Maintainers will be a crucial part of a successful code quality review, which leads me to the governance... The current list of modules is there: http://community.kde.org/Frameworks/List As you can see there's quite some holes in the table, and quite a few entries marked unmaintained. KDE Frameworks as a set of technologies will only be taken seriously if we get something more complete there. I urge everyone with an interest in KDE Frameworks to step up, look at that list and volunteer to maintain a framework. If you volunteer, know that the following will be expected from you: 1) Complete in the table the information regarding your framework; 2) Do an API review and modernization pass in your framework (possibly with the help of others); I've put myself down (rather obviously) for KPrintUtils. How surprising. :-) Most of the dialog code from there has been merged into Qt5.2, or is planned for Qt 5.3, so needs deleting. I'm also wondering if we still need our own KPrintPreview dialog, there was a reason in 4.0 but I can't remember why now and I'm not sure it is still valid. Alex Merry might remember, was it because QPrintPreview wasn't available at the time? We may not end up with much left here :-) Well, the initial plan was to not have KPrintUtils at all. It's here mainly because of timing issues because the necessary upstream work to get everything to disappear in KPrintUtils wasn't done in time for Qt 5.2. If the original author Petri Damstén doesn't step up, I could take on KUnitConversion, seeing as I'm partly familiar with the code. Then put your name in front with a note for Petri to kick you off if he shows up. :-) I don't think we've been in touch with him yet. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Tuesday 07 January 2014 23:30:28 John Layt wrote: On 7 January 2014 19:49, Kevin Ottens er...@kde.org wrote: Most of the dialog code from there has been merged into Qt5.2, or is planned for Qt 5.3, so needs deleting. I'm also wondering if we still need our own KPrintPreview dialog, there was a reason in 4.0 but I can't remember why now and I'm not sure it is still valid. Alex Merry might remember, was it because QPrintPreview wasn't available at the time? We may not end up with much left here :-) Well, the initial plan was to not have KPrintUtils at all. It's here mainly because of timing issues because the necessary upstream work to get everything to disappear in KPrintUtils wasn't done in time for Qt 5.2. Running through the print dialog features, I'm don't think there is anything left to be upstreamed. There's a couple of very minor CUPS features in the dialog that I don't think anyone uses (mirror page, page border, page label) that I don't really want in Qt, but can add if anyone really makes a fuss. If we decide to replace KPrintPreview with QPrintPreviewDialog then we're just left with the convenience api to create a QPrintDialog that won't actually add anything extra. That could be still worth keeping for a couple of reasons, but it could then move to KGuiAddons. For the record, if that depends on QtPrintSupport it can't make it to KGuiAddons (which should depend only on QtCore and QtGui). The main reason to keep it is future-proofing if we need to add common widgets or extra checks again, in particular I think it may be the only way to do color-managed printing until Qt adds proper support in QtGui. I'm fine keeping it even if it's small. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
Hello, On Monday 06 January 2014 09:33:38 Martin Graesslin wrote: On Monday 06 January 2014 07:52:50 Kevin Ottens wrote: The current list of modules is there: http://community.kde.org/Frameworks/List As you can see there's quite some holes in the table, and quite a few entries marked unmaintained. KDE Frameworks as a set of technologies will only be taken seriously if we get something more complete there. I urge everyone with an interest in KDE Frameworks to step up, look at that list and volunteer to maintain a framework. If you volunteer, know that the following will be expected from you: 1) Complete in the table the information regarding your framework; 2) Do an API review and modernization pass in your framework (possibly with the help of others); 3) Stick around for a long period to act as maintainer (see below for details); 4) The day you want to move away from your duties, do so responsibly, don't just disappear, make sure you pass the torch to someone else (probably the most important point in the list!). I have a question concerning the platforms: must a maintainer be able to support/maintain all platforms or can a maintainer say I only maintain the framework for platform foo? That's a good question. In my opinion it's fine for a maintainer to delegate the duties to make things work on a given platform to someone else, but, he has to be able to answer at all time is this platform supported? is there anything broken there?. I think that's important that at the end of the day the maintainer is the point of contact for the given framework. This is a very important point given that our community comes from a Linux background and testing patches on other platforms requires to buy software and/or new hardware. Of course, for most of the frameworks it shouldn't be an issue (if they're pure Qt), that's a very valid concern for frameworks which make native calls. In that case I think it's very important that we're blunt and honest about the situation. I'd rather see a few frameworks where we claim sorry, we don't support platform X yet/at all, than having a list where we claim we support all platforms for all frameworks while we're in fact lying for some of them. To make a very practical example: so far maintainership of KWindowSystem was in the KWin team, but obviously we can only maintain the X11 part of it. To go with that: can a framework be team maintained? E.g. could I write down KWin team or just write down KWin maintainer to bind the maintainership to KWin as it used to be? I'd rather have a person name to be honest. It's really for the single point of contact situation in case of big troubles and to avoid diluting the responsibility. How in practice the work is then distributed for a framework is to the discretion of the appointed maintainer, if there's a whole team helping all the better. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Monday 06 January 2014 22:26:27 Alexander Neundorf wrote: IMO something like proposing the maintainers and approving them, similar to Qt, would be good, i.e. at least some kind of voting by who we will be governed. Definitely something we'll need at some point. For bootstrapping I'm more looking for volunteers ATM, we have more seats to feel than declared candidates... Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
KDE Frameworks: Moving toward 5.0 final and Governance
Hello all, Now that TP1 is almost out of the door, it is time to move toward the final release and put in place the governance of KDE Frameworks. It is a very large and multi-faceted product, so we will need people with longer term commitment if we want it to shine on release day. ## What's left for a final? Short answer: http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation (Tasks for Final Release section) To get there, we'll move into a monthly release schedule: * Alpha 1, February 1st; * Alpha 2, March 1st; * Beta 1, April 1st; * Beta 2, May 1st; * Final, June 1st; Between beta 2 and final we'll insert release candidates following a shorter weekly cycle to nail down the remaining minor issues. We don't expect the source code to drastically change between now and final. At least, short term, we shouldn't see code flying from one framework to another one. As you can see most of the tasks revolve around the tooling next to the code (CI, buildsystem, apidox, etc.)... Still there's one big elephant missing there as it's not really something actionable: code quality. I urge everyone, and in particular people volunteering to maintain a framework, to do a pass of review of our code base and APIs to modernize them when appropriate. It is a very big task, and in no way can be coordinated in the way we've been working so far. Maintainers will be a crucial part of a successful code quality review, which leads me to the governance... ## Frameworks Governance? I used to say that the maintenance model of kdelibs was David Faure by default. It's great to have someone like David around, but at the same time it's delusional and dangerous to think that he'll always be able to save the day. This model has to stop now. And hopefully having smaller packages will help people to feel responsible for their modules. The current list of modules is there: http://community.kde.org/Frameworks/List As you can see there's quite some holes in the table, and quite a few entries marked unmaintained. KDE Frameworks as a set of technologies will only be taken seriously if we get something more complete there. I urge everyone with an interest in KDE Frameworks to step up, look at that list and volunteer to maintain a framework. If you volunteer, know that the following will be expected from you: 1) Complete in the table the information regarding your framework; 2) Do an API review and modernization pass in your framework (possibly with the help of others); 3) Stick around for a long period to act as maintainer (see below for details); 4) The day you want to move away from your duties, do so responsibly, don't just disappear, make sure you pass the torch to someone else (probably the most important point in the list!). ### Governance at the framework level At the framework level, the maintainer will be responsible for the quality of the code produced. In particular he'll have to make sure the different policies in place are respected inside his module: http://community.kde.org/Frameworks/Policies In practice that means that the day to day activities (and minimum required from a maintainer) will be to: * Review others' code; * Make sure that his module is always in a releasable state (in particular the CI is always green); * Decide on the direction his module is going in case of conflicts. Note that we're not expecting maintainers to have ideas on features or on a direction to give to the module (of course they can, it's just not required). That means it is fine to be more of the reactive type of maintainer if you want to, letting contributors propose directions and trying to move the lines, you just have to pick one in case of conflicting goals. ### Governance at the KDE Frameworks level Because of the structure of KDE Frameworks (which is already more than 50 modules and that number will likely increase again for 5.1), we also need to have a body that looks at the overall coherency of the whole. My goal here is not to create a huge bureaucracy, so we'll start as small as possible and grow if the need arises. To bootstrap this body, we'll reuse something as close to the status quo as possible. In our case that means that the KDE Frameworks Release Team will start with David Faure and myself. The responsibilities of that team will be the following: * Beating the drum on the product rhythms (mostly the release schedule, but also interim meetings); * Defining the content of the overall product; * Defining the rules of work. All of that in the usual KDE fashion, that is by collecting information from the trenches (that is the maintainers and contributors). David will likely focus more on participating in the day to day activities for the release execution. I will likely focus more on facilitating the creation of the product definition, release schedule and policies. That should pretty much reflect what we've been both doing the past few weeks, not
KF5 Update Meeting Minutes Almost 2014
Hello everyone, This is the minutes of the last meeting of 2013. As usual it has been held on #kde-devel at 4pm Paris time. Were present: apol and myself. Announcement: * TP1 is almost ready, forwarding headers work missing * apol has been working on the header generation for KCoreAddons, KGuiAddons and KWidgetsAddons; * he'll cover KArchive and ThreadWeaver next which are blocking TP1; * ervin has been acting behind the scene to get things rolling for TP1; * feels like being a kind of manager, not doing terribly much on the technical front; And that's it for today! Don't party too hard tonight, see you in 2014! Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
