Moving to Bazaar

[Harald Sitter]

KHello World!

At yesterday's meeting we discussed the possibility of moving the packaging of
all KDE core packages to bazaar branches.
The general feeling seemed to be in favor of starting a migration.

Scott, who had reservation about the performance of bzr didn't make it to the
meeting, so we probably should work this out via mail. In general we should 
get every question or problem resolved before starting to use bzr for real.

I propose that we create a testing branch of kdebase-workspace so that people
can try using it for real and find possible flaws. Since workspace also got the
biggest packaging I suppose it should also give a good indication about the
performance.

<james_w> in a few months there will be branches to play with, proper 
launchpad hosting for them, faster bzr, tools to make the work easier, and 
ways to replace e.g. patches.ubuntu.com
...
<james_w> anyone that wants to discuss that sort of thing is encouraged to 
head over to vcs-pkg.org
...
<james_w> for details on what we are up to in Ubuntu you can visit 
https://wiki.ubuntu.com/DistributedDevelopment

Advantages would be:
  * Improved collaboration
  * Improved reviewing capabilities for sponsors
  * Improved error tracing
  * Decreased amount of uploads with minor changes
  * At a more advanced stage of the distributed development, merging with
    Debian should become a lot easier

Disadvantages:
  * One needs to know how to use bzr and bzr builddeb/buildpackage

Remarks:
  * smarter wants to improve the documentation a bit
  * Until the complete Ubuntu Distributed Development model starts everyone
    has to use bzr, otherwise merging with the archive causes some extra work
  * james_w noted, that full-source branches is the way to go, since it makes
    handling "patches" easier
    - This however conflicts with the common sense of good packaging (which
      would suggest patches as patch files rather than applying directly to the
      source)
    - Also it is fairly impossible to use full-source branches for most core   
     KDE
      packages since they are usually fairly big (workspace contains 92 MiB of
      uncompressed data, now say that grows 1 MiB of compressed diff every
      month
      due to regular updates we are pretty easily at 100 MiB, then we have a
     new
      x.* release ever 6 months which causes a compressed diff of at estimated
      10 MiB...)
    - We agreed to look at this once the distributed development is in a more
      advanced state