[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-devel
Subject:    Re: Introducing dgit - git integration with the Debian archive
From:       Jelmer Vernooij <jelmer () samba ! org>
Date:       2013-08-30 23:37:32
Message-ID: 20130830233732.GA10118 () vernstok ! nl
[Download RAW message or body]

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20130830233732.GA10118@vernstok.nl

[prev in list] [next in list] [prev in thread] [next in thread]