KF5 Update Meeting Minutes 2014-w28

[Ben Cooksley]

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

Hi Kevin,

>
> On Wednesday 09 July 2014 09:57:27 Ben Cooksley wrote:
>> On 9 July 2014 03:30, Kevin Ottens <ervin at 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.

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

>
>> >  * 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).

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...

>
> Hope that clarifies.

It certainly does.

>
> Regards.
> --
> Kévin Ottens, http://ervin.ipsquad.net
>
> KDAB - proud supporter of KDE, http://www.kdab.com
>

Thanks,
Ben