Moving to Bazaar
Yuriy Kozlov
yuriy-kozlov at kubuntu.org
Thu Nov 27 15:06:57 GMT 2008
This seems relevant to this discussion:
https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-November/000514.html
On Wed, Nov 19, 2008 at 8:33 AM, Harald Sitter <apachelogger at ubuntu.com> wrote:
> 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
>
>
>
> --
> kubuntu-devel mailing list
> kubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
>
More information about the kubuntu-devel
mailing list