Plasma/20101125

Meeting Overview

Topic of Meeting

This meeting, held on #plasma on irc.freenode.net on November 25, 2010, was held to discuss issues around the git migration and the KDE Plasma Workspaces, which includes both Plasma and KWin as well as other projects in kdebase-workspace. A full log of the meeting is here

Meeting Attendees

Meeting attendees included (in alphabetical order):

• Aaron Seigo
• Artur de Souza
• Boudewijn Rempt
• Chani
• Ian Monroe
• Ivan Čukić
• Marco Martin
• Martin Graesslin

(If you were in attendance and missing from the above list, please add your name)

Topics

kdeplasma-addons Migration

• Migration rules are complete and ready for a Dec 20 migration, which matches that of other modules such as kdepim

kdebase-workspace Migration

• It seems likely that Ian Monroe will be writing the git migration rules for kdebase and kdelibs
• Consensus is to divide kdebase into three git modules, one each for runtime, apps and workspace
• The best result would be land kdebase simultaneously with kdeplasma-addons (Dec 20), but it wouldn't be the end of the world if it didn't happen before the new year

Git Workflow

There was no final consensus on the workflow. Instead, useful and collaborative discussion was had with the conclusion to take all of the input under further thought and to come back to the discussion again after everyone has had some time to go through it.

• We'd like to have a similar workflow for both kwin and plasma projects so that it is easy to keep increasing the level of cooperation and cross-project effort and support.
• There is interest in allowing for feature and other development to continue unabated at all times, even when release engineering mandates a feature freeze. This would be achieved by having a release branch that follows the release schedule, but all development happening elsewhere without pause.
• It was raised that we probably will only be able to get a rough idea before we start of how we want to set up the workflow and be open to adjusting it as we go. This means that the first devel cycle with git will likely be a bit more uneven than most in terms of workflow
• A devel branch would be maintained and open for additions at all times
  • Features are integrated into (though not developed in) this branch
  • Allows testing by the combined team of developers and "bleeding edge" testers (e.g. used for snapshot builds as offered by, e.g., OpenSuse)
• Feature branches for new features
  • The question is whether anything that requires more than and handful of hours to do should require a branch (high barrier to entry)
  • If all features go into branches, then merging down into an "always releasable" release branch is made easier
  • Feature branches will be merged when deemed ready for broader testing into the main shared development branch
  • Feature branches can be merged into the devel branch "continuously" allowing new features that have reach a certain amount of stability/usability to be tested by the whole team, checked for integration issues, etc. while development remains compartmentalized in the branch
• A release branch is maintained for the purpose of release engineering, and merging from the devel branch to the release branch is done periodically.
  • One possibility is to make the release branch "always releasable", meaning that it is at any given point in time able to pulled from to make a release. This implication of this is that no primary development ever happens in this branch, and it is only a final destination for completed work
  • Merging of features would stop during the time when the release schedule mandates a freeze, allowing the possibility of decoupling development pace from release engineering schedules.
  • It was not determined how to mark or schedule features for merging; possibly by marking feature branches as "ready" (and keeping those markings in order to make merging easier)
• A separate branch for bug fixing?
  • Bugfixes could be committed directly to the release branch and then merged into the devel branch; the concern is that some bug fixes end up introducing unintentional defects that need later fixing which would impact the day-to-day quality of the release branch. This probably only matters in the "release branch always releasable" scenario.
  • This branch would follow the release branch, but be slightly "ahead" of it in terms of bug fixes made
  • Whether each bug fix should go into a branch of its own or just be landed entirely into the bug fix branch is still undecided.
    • Benefits of "branch per bug fix" is the ease of keeping multiple commits (including "fixing the fixes") together
    • Benefits of committing directly to the fixes branch is lower barrier to entry and less merging work
  • Commits to the bug fix branch will be merged into the devel (if applicable) and release branches (in whatever forms those take)