Re: KDE Frameworks: Moving toward 5.0 final and Governance
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? 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. 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? Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: KClasses vs. Qt5Classes
Le mardi 31 décembre 2013 12:42:22 Martin Graesslin a écrit : On Tuesday 31 December 2013 12:15:09 David Faure wrote: QSystemTrayIcon = KNotificationItem No clue. I can't even find KNotificationItem in KF5 anywhere !?!? In fact it doesn't exist in kdelibs4 either. I think it got replaced with KStatusNotifierItem since 4.4 ? That one is still valid in KF5 (framework knotifications). I have no idea if/why it means QSystemTrayIcon is bad though. QSystemTrayIcon uses XEmbed which is bad by definition ;-) We have discussed this in the plasma team and think that the best solution would be to extend QSystemTrayIcon to use the status notifier API if available. Might need some hooks into the QPA as we probably cannot depend on D-Bus on that level. But as that doesn't exist yet, at the moment the proper suggestion should be to use KStatusNotifierItem. For what it's worth, I created something like that for Qt4 while I was at Canonical: sni-qt [1]. It requires a Qt patch though. The patch is in the sni-qt tarball (and here [2]) Aurélien [1]: https://launchpad.net/sni-qt [2]: http://bazaar.launchpad.net/~indicator-applet-developers/sni-qt/trunk.13.04/view/head:/patches/qsystemtrayicon-plugin-system-4.7.4.diff
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.
Review Request 114889: Fix KIO::convertSize(...) returning string with (I18N_ARGUMENT_MISSING) inside
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114889/ --- Review request for kdelibs. Repository: kio Description --- Seems the code behind i18n() in kf5 does not like %-placeholders without any arguments passed in the i18n call. And thus inserts the warning. (Effect can be seen e.g. in Okteta's File Info tool). Attached patch fixes that, by delaying the argument substitution as proposed in http://api.kde.org/frameworks-5.x-api/frameworks-apidocs/ki18n/html/prg_guide.html#spec_usage Diffs - src/core/global.cpp 42f453b Diff: https://git.reviewboard.kde.org/r/114889/diff/ Testing --- Results of KIO::convertSize(...) displays fine in Okteta with the patch. Thanks, Friedrich W. H. Kossebau
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Monday 06 January 2014, Kevin Ottens wrote: 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). 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. Alex
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.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
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 I may also be interested in kconfigwidgets, kcmutils, kcompletion, and kguiaddons in the future (I don't know the code good enough yet). Christoph Feck (kdepepo)
Re: Review Request 112335: In oxygen: Use the iconSize from mainToolbar
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/112335/#review46952 --- Hey hugo, is this in somehow now that oxygen uses KStyle again? - Àlex Fiestas On Aug. 28, 2013, 5:09 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/112335/ --- (Updated Aug. 28, 2013, 5:09 p.m.) Review request for kde-workspace and Hugo Pereira Da Costa. Repository: kde-workspace Description --- In the qplatformplugin we use information from MainToolbar (which makes sense) but in the styles we use information from Toolbar. This unify both by using MainToolbar in styles (if accepted will modify kstyle as well). Diffs - kstyles/oxygen/oxygenstyle.cpp 83aaf5c Diff: https://git.reviewboard.kde.org/r/112335/diff/ Testing --- Thanks, Àlex Fiestas
Re: Review Request 111164: Create FavIconsModule namespace in kdebug
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/64/#review46953 --- This review has been submitted with commit 1346d19ad2716dc69aa612279460ecd4ef0c1234 by Àlex Fiestas to branch master. - Commit Hook On June 21, 2013, 6:55 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/64/ --- (Updated June 21, 2013, 6:55 p.m.) Review request for KDE Base Apps and David Faure. Repository: kde-baseapps Description --- Make FaviIconsModule a better neighbor of the KDED community by having its own namespace :p Diffs - lib/konq/favicons/favicons.cpp 45d6c19 Diff: https://git.reviewboard.kde.org/r/64/diff/ Testing --- Thanks, Àlex Fiestas
Re: Review Request 111164: Create FavIconsModule namespace in kdebug
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/64/ --- (Updated Jan. 7, 2014, 5:50 a.m.) Status -- This change has been marked as submitted. Review request for KDE Base Apps and David Faure. Repository: kde-baseapps Description --- Make FaviIconsModule a better neighbor of the KDED community by having its own namespace :p Diffs - lib/konq/favicons/favicons.cpp 45d6c19 Diff: https://git.reviewboard.kde.org/r/64/diff/ Testing --- Thanks, Àlex Fiestas
