DevHeads.net

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:
<a href="http://i.imgur.com/zokLHVe.png" title="http://i.imgur.com/zokLHVe.png">http://i.imgur.com/zokLHVe.png</a> ;
* 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.

Comments

Re: KF5 Update Meeting Minutes 2014-w28

By Ben Cooksley at 07/08/2014 - 16:57

On 9 July 2014 03:30, Kevin Ottens < ... at kde dot org> wrote:
Hi Kevin,

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?

Expand on strengthen please?

Thanks,
Ben

Re: KF5 Update Meeting Minutes 2014-w28

By Kevin Ottens at 07/09/2014 - 00:14

Hello,

On Wednesday 09 July 2014 09:57:27 Ben Cooksley wrote:
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.

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.

Re: KF5 Update Meeting Minutes 2014-w28

By John Layt at 07/09/2014 - 05:53

On 9 July 2014 06:14, Kevin Ottens < ... at kde dot org> wrote:
I've had clarification from Montel, and indeed the schedule has been
moved up due to there being no 4.15, so now after 4.14 in say
September/October time frame. We have a PIM Sprint planned for
November in Munich when I guess the Frameworks planning will be the
main focus.

The Frameworks branch does build, has many build fixes applied to it
for KF5 and gets regular merges from master. However we're still
doing new features and bug fixes in kdepimlibs as needed for
improvements to the apps, hence the reluctance to split it off before
necessary. I think many of the libs are already fairly standalone,
but others will need considerable restructuring. A few like KHolidays
could be split off and released almost immediately, others will take
much longer. The really big hurdle for pimlibs will be removing
KDateTime/KTimeZone/KLocale usage which is substantial work. There's
some initial work towards the split at [1].

Cheers!

John.

[1] <a href="https://community.kde.org/Frameworks/Epics/kdepimlibs" title="https://community.kde.org/Frameworks/Epics/kdepimlibs">https://community.kde.org/Frameworks/Epics/kdepimlibs</a>

Re: KF5 Update Meeting Minutes 2014-w28

By Ben Cooksley at 07/09/2014 - 00:41

On 9 July 2014 17:14, Kevin Ottens < ... at kde dot org> wrote:
Hi Kevin,

Ah, oki. I thought you meant it hadn't been started yet, which is why
I was confused.

Coverage data shouldn't be too much of a problem - at least for Linux.
I've no idea what happens on other platforms though.
The primary constraints here are the size of the repository, and the
latency to the build master (currently hosted on one of our Hetzner
servers).

Presenting it in the same dashboard is basically blocked only by
getting our configuration made declarative for Jenkins.
Once that is done we can begin adding build nodes for the respective
platforms without too much problem, at least on the Jenkins side.

I expect the CI scripts will also need adapting. Some parts of the
configuration are already duplicative, and other parts have proved
problematic for both early experiments on Windows and OS X. I'm also
aware that Windows has path length restrictions which we'll need to
keep in mind and may necessitate changes in how we currently store
builds.

One major stumbling block at the moment is QStandardPaths - which
doesn't support environment variables of any description on Windows or
OSX. This needs to be fixed, or a different approach taken to how the
CI system handles builds.

Help with the three above items would be appreciated.

I'd like more details on how an Android setup would work - would this
be a x86 or ARM based? For ARM we'd need to either emulate and
virtualise or have physical hardware...

It certainly does.

Thanks,
Ben

Re: KF5 Update Meeting Minutes 2014-w28

By Alex Merry at 07/08/2014 - 12:53

On Tuesday 08 July 2014 17:30:19 Kevin Ottens wrote:
Sorry, life's a bit crazy at the mo. Will try to look at soon. Although I'd
appreciate the input of anyone else with android development experience.

My plans:
* more tests for ECM
* work on rewriting/cleaning up image format handlers
* get the remaining KImageIO methods into QImageReader/Writer

I also second the "better docs" call.

Alex

Re: KF5 Update Meeting Minutes 2014-w28

By John Layt at 07/08/2014 - 12:27

Seconded, especially from the point-of-view of external devs. For
example, someone today was asking about KArchive and whether it was
fully standalone or depended on external libs that they needed to ship
on non-Linux platforms, but the apidocs don't mention the dependencies
anywhere. We need to document every single library from the point of
view of someone completely new to KDE who just wants one single
library in their Qt app.

Do we have a single home page or landing point that we want all
potential users to start from? Do we have general docs to point to
about build chain, licences, getting help, etc? We have the community
wiki but it is not meant to be for that purpose, and the apidox main
page may be too static to keep up with FAQs, so we probably need to
create some TechBase pages. Actually, TechBase is really going to
need a big review.

We already have a link to the donations page buried deep in the "About
KDE" dialog under the "Support KDE" tab where no-one ever sees it. A
Help menu item for "Donate to KDE..." that pops up a dialog explaining
why would be far more visible, but easily disabled by distros who
object. We could also include a "Donate to KDE" tip in every
KTipDatabase and ensure it's the first tip shown by default on an apps
first run. As an admin note, whenever we do add a donate link
anywhere we should make it unique so that we can track how successful
each channel is.

I asked on the PIM list the other day, Montel says the plan is not to
start on frameworks until after 4.15, so maybe March/April next year?
I think he meant porting the PIM applications though, so I'm not sure
what that means for starting on pimlibs. I'll follow up.

My plans:
* Write proper docs for KUnitConversion
* Make KUnitConversion Tier 1 by switching to Qt translations
* In advanced planning for replacements for ISO codes and flag images,
even have some code, see
<a href="https://community.kde.org/KDE_Core/KDE_Open_Data" title="https://community.kde.org/KDE_Core/KDE_Open_Data">https://community.kde.org/KDE_Core/KDE_Open_Data</a>
** OpenCodes: repo of json files of ISO data auto-extracted from
Wikidata, CC-0, can be used by anyone
** KCodes: Qt library which loads OpenCodes files
** OpenFlags: repo of SVG flag images auto-extracted from Wikidata,
with icon set auto-generated from SVGs

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?

Cheers!

John.

Re: KF5 Update Meeting Minutes 2014-w28

By Mario Fux at 07/08/2014 - 16:15

Am Dienstag, 08. Juli 2014, 19.27:52 schrieb John Layt:

Morning John

[snip]

Indeed there is something ;-).

So what? It's still free software so everybody can patch it away. But we can
present it prominently and try and see if it helps. And I mainly think about
KDE apps on Windows, Mac and Android when I want to see this donate button as
we're the distributors there ourselves.

But it's exactly what I meant: A "Donate to KDE..." menu item under the Help
menu.

+1

There won't be a 4.15 and I talked with Montel about this.

Very interesting stuff!

Thx
Mario

Re: KF5 Update Meeting Minutes 2014-w28

By Boudewijn Rempt at 07/08/2014 - 15:10

As a datapoint, and not something most apps will want to do... Adding a
splash screen with a donation link to the development build of Krita meant
getting three out-of-the-blue donations a week more than the zero I had
before. No huge numbers, but then, Krita still is small compared to other
apps.

Boud

Re: KF5 Update Meeting Minutes 2014-w28

By Kevin Ottens at 07/08/2014 - 14:03

On Tuesday 08 July 2014 18:27:52 John Layt wrote:
Not really a bike-shedding topic hopefully... We had the case already and we
used K.

Regards.

Re: KF5 Update Meeting Minutes 2014-w28

By Mario Fux at 07/08/2014 - 11:05

Am Dienstag, 08. Juli 2014, 17.30:19 schrieb Kevin Ottens:
Morning

[snip]

There was a small misunderstanding (probably based on my fatigue brain atm).
Of course this interpretation would be nice as well I meant apps based on KF5
and to get a channel to our users. Two way:
- Get to them if we need (financial) support or want to tell them about new
version or other stuff
- They send us automatically and agreed upon data about their use of our apps.

[snip]

griits
Mario

Re: KF5 Update Meeting Minutes 2014-w28

By Ben Cooksley at 07/08/2014 - 16:54

On 9 July 2014 04:05, Mario Fux <kde- ... at unormal dot org> wrote:
Hi Mario,

How exactly has the Windows CI gotten stuck? I'm aware that while our
scripts are portable the environment they rely upon does tend to be
quite hostile - especially due to weaknesses in the non-X11 parts of
Qt. It also seems that we may need to shift to some form of
declarative configuration rather than the current INI based setup we
have at the moment. (To be able to accommodate the various other
differences in platforms I did not anticipate)

As a note to all those interested in having various types of builds
being run, we're going to need to shift towards a different method of
configuring Jenkins. The current method isn't sustainable i'm afraid.
We're essentially copying jobs to configure the system at the moment.
Adding other platforms will require using Multi-Configuration jobs,
which means we have to reconfigure from scratch.

Two solutions i've found are
<a href="http://ci.openstack.org/jenkins-job-builder/builders.html#builders" title="http://ci.openstack.org/jenkins-job-builder/builders.html#builders">http://ci.openstack.org/jenkins-job-builder/builders.html#builders</a> and
<a href="https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin" title="https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin">https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin</a>

Help moving the system configuration towards a setup such as one of
the two above would be appreciated.

Thanks,
Ben