Hi. I'm here to plug dgit, which is a system for treating the Debian
archive like a git remote.
-I'm going to talk for about 35 minutess and then I'll take questions.
+I'm going to talk for about 20 minutess and then I'll take questions.
Firstly, a bit of framing.
dgit can't currently upload to DELAYED queues, which makes it a bit
awkward for a fire-and-forget NMU. One way to implement this would be
to push to the suite branch but send the package upload to DELAYED.
-But such an upload which was deleted by the maintainer still present
-in the suite branch, and the changes might be resurrected by a future
-dgit user. At the very least there should be a way for the maintainer
-to revert a push which was accompanied by a DELAYED upload.
+But such an upload which was deleted by the maintainer would still
+present be in the suite branch, and the changes might be resurrected
+by a future dgit user. At the very least there should be a way for
+the maintainer to revert a push which was accompanied by a DELAYED
+upload.
The other implementation would have the pushed branch stashed away
somewhere and "revealed" only when it was ready, if it was still a
-fast forward. That makes it tricker for someone else to build on it,
-and is more work to implement, but it's probably better.
+fast forward. That makes it tricker for someone else to find it to
+work on top of it, and is more work to implement, but it's probably
+better.
-It would be easy for dgit to construct the NMUdiff and email it to the
-BTS. Of course a maintainer can fetch your NMU easily with dgit, but
-maybe the maintainer isn't using dgit (or, even, isn't using git at
-all).
+It would be easy for dgit, when pushing an NMU, to construct the
+NMUdiff and email it to the BTS. Of course a maintainer can fetch
+your NMU as git commits easily with dgit fetch, but maybe the
+maintainer isn't using dgit (or, even, isn't using git at all), so you
+for the benefit of those maintainers we should still be sending these
+diffs.
-dgit push is slight more work than it needs to be when doing a
+dgit push is slightly more work than it needs to be when doing a
source-only upload. In this case there is not really any need for a
-separate `dgit build-source' step. I think dgit push should make the
-source package as well, since it easily can.
+separate `dgit build-source' step. I think there should be a way to
+have dgit push make the source package as well, since it easily can.
The dgit git server has most of the moving parts to become a
In particular, with the use of signed pushes, we could have
traceability of pushes, which makes a gitish packaging workflow more
-practical - in particular, maintainers would not need to audit work
-found on for-upload branches on the git server, before pushing the
-code to the archive. (I suspect many maintainers already don't do
-this as thoroughly as they should.)
+practical - in particular, maintainers would not need to as thoroughly
+audit work found on for-upload branches on the git server, before
+pushing the code to the archive. (I suspect many maintainers already
+don't do this as thoroughly as they should.)
dgit requires the suite branches to be fast forwarding. If you have a
-workflow involving git rebase, you need to make a fake merge (ie,
-merges made with git merge -s ours), at the tip of your branch, to
-make it be a fast forward from the previous state of the suite branch.
-And then when you want to work on the package again, you need to strip
+workflow involving git rebase, you need to make a fake merge (ie, a
+merge made with git merge -s ours), at the tip of your branch, to make
+it be a fast forward from the previous state of the suite branch. And
+then when you want to work on the package again, you need to strip
that same fake merge.
This can be done with raw git operations (git merge and git reset)
quite easily, but it's ugly. Also doing it by hand like this doesn't
provide many safety catches.
-I intend to provide some tooling which will help with this.
+I intend to provide some tooling which will help with this, but I
+haven't exactly decided what the UI should be and how it should work.
The final thing I can do myself is arrange for non-dgit uploads to be
automatically converted, and appended to the dgit suite branches on
-the dgit git server. That would make the dgit history for any package
-be more useful, starting with the first dgit-based upload. In
-particular it would avoid the browse.dgit.debian.org view ever being
-out of date.
+the dgit git server. That would make the dgit history, as shown on
+browse.dgit.debian.org for example, for any package be more useful,
+starting with the first dgit-based upload. In particular it would
+avoid the browse view ever being out of date.
There are also some things that I need help with.
tool's favoured history format, and how to upgrade a package to a new
upstream version.
-That bug is request against git-dpm for new manpage covering these
-topics, since I think the moving parts for git-dpm to work with dgit
-are generally in place.
+The bug I mention there is my request against git-dpm for anew manpage
+covering these topics, since I think the moving parts for git-dpm to
+work with dgit are generally in place.
And this leads on to the question of how to use git-buildpackage and
dgit together. As I say, I'm talking to the gbp maintainers.
-And then there are a couple of exciting possibilities:
+And then there are a couple of exciting possibilities for new uses:
Firstly, it would be very nice to have a way for a sponsee to provide
a dgitish git branch, which the sponsor could work with directly and
-ultimately dgit push.
+ultimately dgit push. I'm really need to talk about this with some
+people more familiar than me with the sponsorship queue infrastructure.
Secondly, dgit is not just for Debian. Other distros currently using
-only source packages have use it too. Read-only support doesn't
-necessarily depend on specific support at the distro end. You can
+only source packages can use it too. Read-only support doesn't
+necessarily depend on specific support at the distro end. So, you can
already dgit fetch from ubuntu; I'd welcome patches for read-only
support for Mint, for example.
-dgit push support requires a suitably set up git server. I hear
-rumours that Ubuntu might grow such a thing.
+dgit push support requires a suitably set up git server, and maybe
+some thought, depending on the distro's views on push access control.
+I hear rumours that Ubuntu might grow a dgit git server and support
+dgit push. Patches very welcome!
So that's most of what I have prepared. There's, of course, a lot
~ijackson / talk-2015-debconf-dgit.git / commitdiff