Moving to Bazaar
Harald Sitter
apachelogger at ubuntu.com
Wed Nov 19 13:33:35 GMT 2008
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
More information about the kubuntu-devel
mailing list