Meeting Notes

Branch Policy

There is no branch, everything happens in master.

Feature branches: Should be very short lived, if they live longer than 2-3 weeks look at splitting them into smaller changes. Might not be best suited for ReviewBoard review, alternative review approaches are allowed. Rebase/split into independent commits is possible, force pushing is currently disabled on the main repos (possible on personal clones, or with new branches).

Lack of long term stable branches caused concerns from packagers initially, try it nevertheless for now and see how well it works.

Commit Hooks and Reviews

Marco suggested a hook to check for the REVIEW tag, with a way to by-pass it quickly with "REVIEW: trust-me", just to force you to think about review. We want that.

Mandatory all-time review vs. non-review bypass option?

available manpower, threshold to do minor changes

we had a few cases of breakage due to skipped reviews

Gerrit:

Jan has it set up and ready for usage, interested repos need to be added manually at the moment (on both Gerrit and KDE Git sides)

anyone can push, any KDE developer can approve, Gitolite unaffected (direct pushes are still possible)

Jan is still working on pre-approval CI integration

How do the KDE Sysadmin feel about Gerrit?

Try on a few projects without really changing the current workflow, details on review policy configuration (self-approval, etc) for Gerrit left for later, first gain some experience with it.

Parallel use with current workflow is no problem, not conflicting with ReviewBoard and Gitolite.

similar problem exists for all frameworks that search for data files, all need similar test setup options

Extra/betters tools for tests? See Shantanu's talk from yesterday and Zanshin for mock examples, currently not used in KF5 (yet).

Coverage not currently enabled on Jenkins, we would like to have that enabled for KF5. Needs an option to set the coverage build flags (got removed from ECM). Does Jenkins have enough computing power? Aleix will look into it.

Unstable tests? Either make stable or disable, there is no other way around that.

License Policy

Currently Qt code can't be copied into KDE lacking the LGPLv3 compatibility, but that is going to change. Do we need/want to adjust the license policy? Currently not really needed, wait until the need for this actually comes up.

Developer Story / SDK

Followup to the discussion in Randa on this topic.

CI/Jenkins skills missing, for:

adding non-Linux (Android, Windows).

generating tarballs and releases

Script for automagic environment setup to install distro-provided dependencies and build the rest, possibly based on kdesrc-build.

Documentation should be linked inside Qt documentation/Assistant.

kdesrc-build focus on contributor use, inqlude focus on KF5 users.

KDE specific tools in KDevelop (access to recent bugs, reviews, etc).

Android Support

Aleix working on CMake support.

Needs CI, running tests is tricky though.

Distribution channels: Aleix has a proof-of-concept for F-Droid. KDE could have its own F-Droid repository.
Alternative: Play Store, less FOSS-friendly, might still have legal risks, but we could charge money there. Publish via single KDE account (via KDE e.V.)?
In any case, we want a single recommended way for getting KDE apps into some Android app store. Details to be discussed, includes technically, legal and organizational issues.

Non-Linux CI

Small Patrick is working on Windows support on Jenkins (using an old workstation at Large Patrick's place, might need more power later), biggest challenges are porting the Unix CI scripts, and KDE CI specific Qt patches.