CP rollout plan

[Harald Sitter]

As previously discussed, here's a preliminary plan for continuous packaging.

# stage 1
- recycle neon orchestration tech to build plasma5 workspace from
master using next packaging (this might need branching to support the
fact that we need two packaging versions that are both moving at the
same time)

# stage 2
- introduce auto QA measures and along with that a
proposed/stage/landing PPA which is used to conduct QA before
promotion to live ppa
  - britney?
  - file move detection?
  - auto upgrade testing

# stage 3
- expand CP to frameworks
- expand CP to stable branches

# stage 4
- kick neon in a bin
- possibly expand to more than one series (e.g. one could have trunk,
stable, stable/trusty, trunk/trusty branches ....) this entirely
depends on effort involved etc. generally though with sufficient
degrees of automation one could get to a point where a fix in the
oldest supported version will be forward merged automatically and
subsequently trigger new builds such that ideally one commit can fix
aaaaaaaaaalllllllllll builds for aaaaaaaaaaaaallllllllllllll kubuntu
series

# problem resolutions
- l10n being absent:
  source package builder needs to attempt a smart sed to drop
usr/share/locale/ from installs
- inter-package version dependent packages:
  need to be figured out on a case by case basis, for the time being
this should not be applicable for plasma5 so this will only present an
issue further down the road as more stuff will get covered
- mixed archness (i.e. amd64 built before i386 data makes stuff explode)
  this will be solved by advanced build retry tech doing a deep dep
resolution before attempt a retry. additionally stage 2 QA would
prevent update breakage due to missing arch:all deps

# unresoved problems
- multiple branches are a nightmare for human beings in bzr since a
branch is always a repo and handling multiple repos with different
paths and different folders locally will totally go wrong at some
point. a move to git would be best, question is where to.
- if one is to CP frameworks the package would be the same for trunk
and stable respectively, so someone will need to come up with an idea
to not pointlessly waste resources there (possibly a binary copy
dependency is needed)