more talk

diff --git a/talk.txt b/talk.txt
index 5e6bc206645391c7c17d3957cb8de99cd7ed3c78..24dc9b6d4e19143e4bf8ce84547507223213a7f4 100644 (file)
--- a/talk.txt
+++ b/talk.txt
@@ -307,6 +307,8 @@ differently to the underlying tool, is pass some appropriate -I
 options, to exclude exactly and only the .git directory.
 
 
+==== manpage clean slide
+
 Finally, there is one compelling advantage of dgit's git-based
 approach.
 
@@ -317,16 +319,112 @@ package's clean target entirely.
 
 If you're not in the habit of forgetting to say git-add, you can set a
 configuration option to have dgit always use git-clean.  Then you will
-never have to fight a buggy clean target, in a strange package, ever again.
+never have to fight a buggy clean target, in a strange package, ever
+again.
 
 
 
 ==== Future plans slide
 
-I have a number of plans for the future, some of which I need help
-with.  But I don't have time, I'm afraid, to go through them.
+I have a number of plans for the future, some of which I may even get
+around to:
+
+
+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.
+
+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.
+
+
+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).
+
+
+dgit push is slight 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.
+
+
+The dgit git server has most of the moving parts to become a
+fairly-general-purpose git server with access control equivalent to
+the Debian archive.  In this role it could replace some uses of
+Alioth, which is good because Alioth is doing too many other things.
+
+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.)
+
+
+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
+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.
+
+
+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.
+
+
+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.
+
+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.
+
+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:
+
+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.
+
+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
+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.
 
-Instead, I'm going to open the talk up to questions now.
 
+So that's most of what I have prepared.  There's, of course, a lot
+more detailed information in the manpages.
 
-12 mins
+I'm going to take questions now.