There are also some things that I need help with.
The documentation for how dgit works together with existing git
-management tools is rather sparse. Ideally each git workflow tool
-would explain how (or whether) it works with dgit. Tasks that should
-be covered include how to incorporate changes made in an NMU into the
-tool's favoured history format, and how to upgrade a package to a new
-upstream version.
+management tools is rather sparse.
-I'm talking to the xxx
+Ideally each git workflow tool would explain how (or whether) it works
+with dgit. Tasks that should be covered include how to incorporate
+changes made in an NMU into the tool's favoured history format, and
+how to upgrade a package to a new upstream version. I have spoken to
+the git-buildpackage and git-dpm maintainers about this. I'm
+optimistic particularly about git-buildpackage.
-The bug I mention there is my request against git-dpm for a new
-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.
+There is a difficulty with empty directories in source packages. git
+refuses to handle empty directories - they tend to just vanish from
+commits and checkouts. But I'm told there are some source packages
+whose orig tarballs contain empty directories, and build systems
+depend on those empty directories.
+
+Currently if you dgit clone such a package, it won't build. I don't
+have a particularly good answer to this problem right now. It's no
+good to have dgit create these directories in the working tree, when
+it notices, because the git branches might be transported by plain git
+and used elsewhere.
+
+This can be worked around in the source package by either adding
+something to debian/rules to create these directories, or by adding
+some files to the directories to make them nonempty. But at the
+moment a maintainer is not required to do either of these things.
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. I'm really need to talk about this with some
-people more familiar than me with the sponsorship queue infrastructure.
+people more familiar than me with the sponsorship queue
+infrastructure.
+
+
Secondly, dgit is not just for Debian. Other distros currently using
only source packages can use it too. Read-only support doesn't
dgit push. Patches very welcome!
-xxx==== Thanks and more info slide
+==== Thanks and more info slide
+
+Finally, there are some people I need to thank.
+
+At least half of the design of dgit is Joey Hess's, at the now-famous
+session in Vaumarcus.
+
+Debian System Administration, and particularly Peter Palfrader, have
+been absolutely brilliant. The level of service and competence has
+been outstanding. Ever time I noticed some aspect I had forgotten,
+and made a blatherous and ill-thought-out request, DSA would propose a
+much better alternative and implement their end of it it almost
+immediately.
-xxx thank dsa ftpmaster
+Also, I'd like to thank the ftpmasters for setting up the new
+ftpmaster data service. This has enabled me to extend dgit's
+useability to non-DDs.
So that's most of what I have prepared. There's, of course, a lot
~ijackson / talk-2015-debconf-dgit.git / blobdiff