Improve Ninja's release packaging (once more)

[Harald Sitter]

[caution: this mail grew incredibly long :P]
Hola!

I'd like to discuss a new workflow for KDE release packaging. Latest changes
to the infrastructure (namely the use of bzr and the availablility of a
private PPA) allow us to improve the package update process a lot.

I propose the following changes:

Dettaching from the packaging coordinator dude. Ultimately the Ninjas would
get a server where everyone gets access (at least sftp), so they can upload
the content rather than sending it to a single person. Also it would allow
us to run batch QA tools on the package tree and for example detect moved
files and introduce proper replaces. But since we don't have a server offer,
bzr will have to do :P
The main idea is that, unlike I intent before, maximize commit rate to the
branches. In the best case a ninja would do a commit indicating the changes
(debcommit -R) and a reviewer would commit the relase tag (debcommit -r) ...
considering everything is ok. Worst case would be: ninja fixes more stuff
(committed with debcommit -R in one or more commits) and the reviewer needs
to fix something as well (debcommit -R -r). So, I guess we will use bzr
pretty much like a remote server, just that bzr got tagging support and can
revert stuff :P
 * batget sets the push target for the batbranch to avoid the use of gypsy to
   do an initial push from the batbranch
 * batsend doesn't create a bzr bundle (bzr commit in a file) but pushes the
   commit to launchpad

Centering around the branch, not the source tree. Until now we focused our
efforts on the source tree (copied debian/ to the tree and only left it
once everything was fine).
That concept however is flawed considering we loose the advantages of bzr
by doing so. Reason enough to change that completely.
  * batbuild will be invoked in batbranch/ or the top source directory and
    copy batbranch/debian/ to $package/debian/, then continue as usual (in
    a way this is like bzr-buildpackage, just more powerful ;-)

Stackbuilds for everyone. Primary target ought to be to update the main
dependency chain (libs - pimlibs - bindings - workspace) and deploying it
to the PPA. At least the upload will be done by $reviwer(s) to ensure
everything is fine and prevent a chain reaction of issues (like someone
changes kdelibs5-dev to kdelibs6-dev and everyone changes the build-depends
even though kdelibs5-dev should have never been renamed). Obviously
before uploading the reviewer should review ;-)
I'll add a script that uses the same mehtod as batbuild to export the debian
directory to the source tree, automagically adds ~ppaTIMEDATE to the
version and then uploads to the PPA. Using the batbranch/debian dir as
center of development this approach also prevents that one accidently pulls
these ~ppa changes in (batbuild would overwrite $package/debian/ with un-
ppa'ed changelog from batbranch/).

Reduce testbuilds. No doubt, testbuilds are an essential part of QA, but
they are also the most time consuming one. To improve this situation the
requirements for a good package will change a bit.
Everyone then must pbuild against the PPA main stack with the D10aptupdate
hook to ensure buildability against the main stack as well as most recent
jaunty packages. Before batsending one should have a complete build/BUILDLOG
file including the output of B10list-missing. Then it is up to $reviewer if
they want to testbuild again them selfs or trust the packager or upload to
the PPA (which should be easy enough using the new script but will lack
the list-missing output, which isn't necessary if a BUILDLOG was batsent
though).

Send more information. The new batreports (a collection of the parsed output
of dpkg-source, lintian src, lintian deb, cmake and list-missing hook) allow
a much more precise review and QA. Executing batbuild -b (no build) will
however eliminate the output of 3 sources and thus dumps information.
 * batbuild probably should
   a) name REPORTS coming from a batbuild run with build REPORT.build
   b) scan the previous build/ dirs for REPORT.builds and copy them
      to the current build/ directory to preserve information
   I am not so sure about this, but it is probably the best option to
   preserve build information and at the same time do a batbuild -b.

Opinions? Further suggestions?

regards,
Harald