kubuntu-ci & issues at hand

[Harald Sitter]

ahoy me mateys

to keep y'all posted on the latest developments on the ci front here's
a status update

first off: join #kubuntu-ci if you want ci fail and fixed reports
(mailing list setup to follow at a later point), if you want google
push notifications to your android device I can also make that happen
personally I am not convinced that makes a whole lot of sense though

- jenkins rollout pretty much complete building from
lp:~kubuntu-packagers/kubuntu-packaging-unstable
- jenkins jobs automerge on every build with
lp:~kubuntu-packagers/kubuntu-packaging-next
- commits to the unstable branches automatically trigger a build
- things break a lot \o/
- jenkins blocks builds in sequence to decrease the chance of running
into weird dep wait or fail issues to do with -dev packages
- jenkins could also rebuild packages in sequence if a dependency
changed (e.g. if one changes baloo plasma-workspace could be
automatically rebuilt) this is however presently inactive as it
largely seems a waste of resources

problems:
- bzr merge is really crappy with merging debian dirs. every other
automerge from next fails on either changelog (which is why unstable
currently has no changelog delta with next at all anymore) or control
(which is muchos funnier because bzr trips over commas moving from one
line to another...)
- multiple tightly related branches are a real mess with bzr and very cumbersome
- we need to allow for control over certain parameters (git repo,
branch, svn repo...) as presently builds such as sddm, kscreen and
-wallpapers fail on them not following the overall paradigm of
git.kde.org/name --branch master
- there is substantial ongoing breakage coming from weird packaging to
begin with + ECM/pkg-kde transition + frameworks release + workspace
release, and all of it at once (just to give you an idea: I've pretty
much spent my entire week getting CI to do a complete build every day,
I have not managed to pull that off yet)
- launchpad doesn't like being hammered by bzr checkouts (looking back
I should have set everything up with proper disconnected branches...)
and resets connections in certain cases leading to bogus failures
- bzr is being incredibly slow when run on multiple checkouts at once
and actually managed to create a bunch of zombies (I am really not
sure how it did that...)

^ most of the problems would/will be resolved by not using bzr hence
why it would be really good if someone moved the git migration forward

HS