Difference between revisions of "Frameworks/Meetings/201409Akademy"

Jump to: navigation, search
(Meeting Notes)
Line 40: Line 40:
 
Lack of long term stable branches caused concerns from packagers initially, try it nevertheless for now and see how well it works.
 
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.
  
  
  
 
to be continued...
 
to be continued...

Revision as of 13:05, 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.


to be continued...


Content is available under Creative Commons License SA 4.0 unless otherwise noted.