On Sun, Aug 25, 2013 at 01:04:32PM +0200, Raphael Hertzog wrote: > Hello, > > On Thu, 22 Aug 2013, Ian Jackson wrote: > > I'm pleased to announce that dgit 0.7, which is a version of dgit > > suitable for alpha and beta testers, is available in unstable. > > > > >From the manpage: > > > > dgit [dgit-opts] clone [dgit-opts] package [suite] [./dir|/dir] > > dgit [dgit-opts] fetch|pull [dgit-opts] [suite] > > dgit [dgit-opts] build|sbuild [build-opts] > > dgit [dgit-opts] push [dgit-opts] [suite] > > > > dgit treats the Debian archive as a version control system, and > > bidirectionally gateways between the archive and git. The git > > Basically, this is "Ubuntu Distributed Development" (UDD) but for Debian & > Git (instead of Ubuntu & bzr). > > Have you looked at UDD? They have been doing this for multiple years and > have much more experience than us here. I'm sure there a quite a few > things to learn from what they did to not redo the same mistakes. > > https://wiki.ubuntu.com/DistributedDevelopment > http://developer.ubuntu.com/packaging/html/udd-intro.html > https://launchpad.net/udd > > I'm putting James Westby in CC (as I believe he's one of the core UDD > developers, and also a Debian contributor). He might want to review dgit > and share his hindsights. > > Among notable differences there's that dgit contrary to UDD decentralizes > the creation of the branch with all the archive uploads. But I never used > UDD and don't know it well enough to comment much more than that.
The automatic importer was one of the main problems in UDD. There was a small team responsible for importing all of the archive into bzr. The goal was to import the entire archive and as much history as we could find, including all of the odd packages that live in it. We spent a lot of time dealing with odd source packages - packages that were huge like nexuiz, source packages with multiple upstream tarballs, tarballs with unusual file names that bzr didn't like (e.g. "\"), etc. This centralized approach meant that Ubuntu developers depended on the team building and running the importer to fix bugs and deal with out of date branches when the importer failed. Any errors from the importer wouldn't be visible to them - it ran as a separate cronjob elsewhere, with its output only visible on the package-importer web site. Users weren't empowered to fix bugs. There were a couple of people who contributed fixes to the UDD importer, but this was far harder than it should be, as setting up the importer locally was a pain. In the end, this meant that using UDD had some minor benefits (a richer history, and theoretical improved merge support) but there were a number of extra things you had to watch out for that made it frustrating to use: manually checking sure that the branch was in sync with the archive before using it (and giving up on UDD or prodding us if it wasn't), making sure you pushed the right changes to the UDD branches (otherwise they would be overwritten by the automatic importer). Cloning one of the bzr branches can also be quite slow because of performance issues in bzr that took a long time to fix, and because Launchpad is in the UK, whereas there are a lot of mirrors of the Ubuntu archive. I always considered having the .pc/ directory checked in and the patches applied by default for the quilt format a mistake, as it lead to tons of spurious conflicts during merges. Cheers, Jelmer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130830233732.ga10...@vernstok.nl
