Frameworks/Meetings/201409Akademy: Difference between revisions

From KDE Community Wiki
(→‎Agenda: Gerrit)
 
(11 intermediate revisions by the same user not shown)
Line 3: Line 3:
Hosted by Kevin Ottens and the KDE Frameworks crew.
Hosted by Kevin Ottens and the KDE Frameworks crew.


Notes taken during the meeting on [https://notes.kde.org/p/frameworks-bof-akademy-2014 etherpad]
Notes taken during the meeting on [https://notes.kde.org/p/frameworks-bof-akademy-2014 etherpad] (not really, network not stable enough).


== Agenda ==
== Agenda ==
Line 29: Line 29:
** Windows installers
** Windows installers
** i18n status
** i18n status
== 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.
* There is a test repo for trying it.
* Pay attention to project monitoring and adding reviewers so nothing is lost, handled differently compared to ReviewBoard notifications to mailing lists.
* Try on KIO and plasma-framework until end of year, then re-evaluate.
* We would need new documentation, especially for newbies.
=== Getting More Tests ===
Still low on tests, people would want more.
Push for more tests during reviews, for new stuff.
Make sure automated tests work without installation. Tricky due to ksycoca and QStandardPaths.
QStandardPaths:
* has test mode for local files, but not for system files
* making it more flexible tricky due to Mac/Windows issues
* provide convenience to simplify that setup for tests
* alternative: allow searching in QRC, that's cross-platform and relocatable
* 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.
Someone is working on the same for Mac.
=== Documentation / Book ===
Work on book started in Randa, goal is one chapter per framework. So far: 4-5 chapters/36 pages exist. Can be found in Git, has CMake build system and will get CI. Aim at having a printed book at Qt Dev Days, more chapters needed though.
Marco, Martin G., Martin K., Luigi, David E., David F. each volunteer to write at least one chapter. Tutorials on techbase might be a good source of content. Sebas wrote readmes per framework, might provide useful intro texts for the chapters.
techbase vs. code distance, can the tutorials be maintained next to the code in Git and docs generated from that?
Future of techbase, does the book replace it? No, but some content is being superseded/archived for KDE4. Some restructuring needed.
=== frameworks.kde.org Website ===
Partially covered by the reworked api.kde.org and the book. Improved landing page? Websites tend to get outdated quickly though.
Better home pages for frameworks instead of pointing to projects.kde.org (there's a task for that already).
=== Technical Topics ===
==== libkonq ====
Code sharing between file managers. David F. working on merging this into KIO.
FolderView has a copy of libkonq, goal is to remove that.
Still left to do:
* DnD handling
* Konqueror property menu (unused by Dolphin, but willing to migrate to it)
* some Konqueror specific stuff
* favicon kded module (should probably move to KIO), or replace with shared on-disk data cache? also needed upstream in Qt due to QtWebEngine switch (WebKit did that previously).
==== sycoca replacement ====
Plan from fd.o summit, same approach from the shared mime database. Needs glib-based code to be written, progress so far only during fd.o summit. Problem due to delay: compatibility with already released KF5 code. This so far only covers application desktop files, but plug-ins and services aren't covered (but we assume to can reuse the application part for that). Alternatively we could also move that part forward independently, as there is no point in sharing that with the glib world. Plasma packages also need that. Becomes more of an issue as more and more Plasma packages/plugins appear/are installed.
==== kdepimlibs ====
For KF5 split of kdepimlibs plan see [[KDE_PIM/Meetings/Akademy2014|Notes]] from PIM Bof earlier today.
How and where do we handle KF5 communication with kdepimlibs (and possibly others) joining? Domain discussions can stay where they are, framework coordination/structural discussion can stay together.
==== Accessibility ====
Fredrik wants to kill the system bill and simplify the a11y KCM, some files miss license headers there though.
==== kglobalaccel ====
Runtime part currently in workspace, X11-only (no Wayland) at the moment. Win/Mac not supported/ported. LxQt wants to use this, that would need to move out of workspace. Would increase tier from 1 to 3 though, tier 2 without KCrash (needed for restart). Daemon only needed for Mac, would work on Linux/Windows without that (thus removing the D-Bus dependency there). On Linux, the crash restarting could be done via systemd.
Upstream crash auto-restart feature to Qt would address the KCrash dependency.
Let's move it, or is the tier increase a problem for anything using kglobalaccel on a lower tier (unlikely)? GPL for the daemon is not a problem.
==== Windows Installers ====
Windows teams is working on removing the old complicated UI from the installer and replacing it with something much easier.
==== i18n Status ====
See parallel BoF.
=== Misc ===
Kevin K replaces Kevin O as KF5 project manager.

Latest revision as of 15:19, 9 September 2014

Akademy 2014 Frameworks BoF

Hosted by Kevin Ottens and the KDE Frameworks crew.

Notes taken during the meeting on etherpad (not really, network not stable enough).

Agenda

  • Practices topics
    • Branch policy
    • Commit hooks and reviews -- want to use Gerrit?
    • Getting more tests
    • Licence Policy - would it be useful to allow code from Qt into KF5?
  • Technical topics
    • libkonq
    • sycoca replacement
    • kdepimlibs
    • Accessibility
    • kglobalaccel runtime parts in kglobalaccel itself?
    • Windows installers
    • i18n status

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.
  • There is a test repo for trying it.
  • Pay attention to project monitoring and adding reviewers so nothing is lost, handled differently compared to ReviewBoard notifications to mailing lists.
  • Try on KIO and plasma-framework until end of year, then re-evaluate.
  • We would need new documentation, especially for newbies.

Getting More Tests

Still low on tests, people would want more.

Push for more tests during reviews, for new stuff.

Make sure automated tests work without installation. Tricky due to ksycoca and QStandardPaths.

QStandardPaths:

  • has test mode for local files, but not for system files
  • making it more flexible tricky due to Mac/Windows issues
  • provide convenience to simplify that setup for tests
  • alternative: allow searching in QRC, that's cross-platform and relocatable
  • 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.

Someone is working on the same for Mac.


Documentation / Book

Work on book started in Randa, goal is one chapter per framework. So far: 4-5 chapters/36 pages exist. Can be found in Git, has CMake build system and will get CI. Aim at having a printed book at Qt Dev Days, more chapters needed though.

Marco, Martin G., Martin K., Luigi, David E., David F. each volunteer to write at least one chapter. Tutorials on techbase might be a good source of content. Sebas wrote readmes per framework, might provide useful intro texts for the chapters.

techbase vs. code distance, can the tutorials be maintained next to the code in Git and docs generated from that?

Future of techbase, does the book replace it? No, but some content is being superseded/archived for KDE4. Some restructuring needed.


frameworks.kde.org Website

Partially covered by the reworked api.kde.org and the book. Improved landing page? Websites tend to get outdated quickly though.

Better home pages for frameworks instead of pointing to projects.kde.org (there's a task for that already).


Technical Topics

libkonq

Code sharing between file managers. David F. working on merging this into KIO.

FolderView has a copy of libkonq, goal is to remove that.

Still left to do:

  • DnD handling
  • Konqueror property menu (unused by Dolphin, but willing to migrate to it)
  • some Konqueror specific stuff
  • favicon kded module (should probably move to KIO), or replace with shared on-disk data cache? also needed upstream in Qt due to QtWebEngine switch (WebKit did that previously).

sycoca replacement

Plan from fd.o summit, same approach from the shared mime database. Needs glib-based code to be written, progress so far only during fd.o summit. Problem due to delay: compatibility with already released KF5 code. This so far only covers application desktop files, but plug-ins and services aren't covered (but we assume to can reuse the application part for that). Alternatively we could also move that part forward independently, as there is no point in sharing that with the glib world. Plasma packages also need that. Becomes more of an issue as more and more Plasma packages/plugins appear/are installed.

kdepimlibs

For KF5 split of kdepimlibs plan see Notes from PIM Bof earlier today.

How and where do we handle KF5 communication with kdepimlibs (and possibly others) joining? Domain discussions can stay where they are, framework coordination/structural discussion can stay together.

Accessibility

Fredrik wants to kill the system bill and simplify the a11y KCM, some files miss license headers there though.

kglobalaccel

Runtime part currently in workspace, X11-only (no Wayland) at the moment. Win/Mac not supported/ported. LxQt wants to use this, that would need to move out of workspace. Would increase tier from 1 to 3 though, tier 2 without KCrash (needed for restart). Daemon only needed for Mac, would work on Linux/Windows without that (thus removing the D-Bus dependency there). On Linux, the crash restarting could be done via systemd.

Upstream crash auto-restart feature to Qt would address the KCrash dependency.

Let's move it, or is the tier increase a problem for anything using kglobalaccel on a lower tier (unlikely)? GPL for the daemon is not a problem.

Windows Installers

Windows teams is working on removing the old complicated UI from the installer and replacing it with something much easier.

i18n Status

See parallel BoF.

Misc

Kevin K replaces Kevin O as KF5 project manager.

Retrieved from "https://community.kde.org/index.php?title=Frameworks/Meetings/201409Akademy&oldid=39547"