more talk

diff --git a/talk.txt b/talk.txt
index 8e1a0b24d2af9187f60247e818bbb92de8b88d50..64142cdc67f043be87ec6cdc37a59f2107547976 100644 (file)
--- a/talk.txt
+++ b/talk.txt
@@ -13,9 +13,9 @@ difference is between the maintainer (or maintainers) of a package,
 working on their own package, and everyone else.
 
 I'm going to start by presenting dgit from the point of view of
-everyone else: NMUers, sponsorship, teams doing cross-archive work
-like transitions and reproducible builds, bug squashers, downstreams,
-users, and so on.  Maintainers, please be patient - I'll get to you.
+everyone else: NMUers, sponsorship, bug squashers, downstreams,
+users, teams doing cross-archive work
+like transitions and reproducible builds, and so on.  Maintainers, please be patient - I'll get to you.
 
 
 ==== data flow slide
@@ -35,9 +35,10 @@ with any other project.  In particular, you can:
  * git reset, git clean
  * git rebase -i to polish a more complex set of changes into
    a patch queue
+ * all of the usual gitish stuff
 
-If you have the right authority you can also dgit push, to upload
-(after doing a build).
+If you have the right authority you can also dgit push, to upload.
+You still have to do a build.
 
 If you want so share your work-in-progress with others, you can git
 push your branch anywhere suitable, so they can fetch it.  So, for
@@ -48,15 +49,15 @@ then approve it by running dgit push.
 
 The dgit history structure is up to the maintainer.  If you are doing
 a straightforward NMU you should produce a well-structured linear
-sequence of commits, as you would for any git upstream.  If the source
-package is `3.0 (quilt)', you shouldn't touch debian/patches; dgit
-will take care of that for you.
+sequence of commits, as you would for any other git upstream.  If the
+source package is `3.0 (quilt)', you shouldn't touch debian/patches;
+dgit will take care of that for you.
 
 ==== NMU linear history on top of basic dgit history
 
-Unless the maintainer uses dgit, the history you see in dgit will not
-be the maintainer's history.  This is because maintainers' git
-branches often differ from the source packages in the archive.
+Sadly, unless the maintainer uses dgit, the history you see in dgit
+will not be the maintainer's history.  This is because maintainers'
+git branches often differ from the source packages in the archive.
 
 So dgit may have to synthesise a git history.  The history you see in
 dgit will then have a very basic branch and commit structure, rather
@@ -69,7 +70,8 @@ maintainers:
 ==== history comparison slide
 
 For the reasons I've explained, downstream dgit users would like you
-to use dgit push.  They will then be able to see, and directly work
+as a maintainer
+to use dgit push to do your uploads.  They will then be able to see, and directly work
 with, your own history.
 
 But it's in your own interests, too:
@@ -106,7 +108,7 @@ directly from dgit's goals.
 The most important requirement is that your git tree is identical to
 the unpacked source package.  (Technically, in the case of a `3.0
 (quilt)' package, it is what is sometimes called a `patches-applied
-packaging branch without .pc'.)
+packaging branch without .pc directory', if you know what that means.)
 
 For all native packages, and for users of git-dpm and raw git, this is
 already the interchange format.  These maintainers can start using
@@ -116,8 +118,10 @@ For those using git-buildpackage with `3.0 (quilt)', things are a bit
 more complicated.  I'm told that gbp pq can be used to generate a
 patches-applied branch, and that some users prefer to use that as the
 interchange git branch, but I know this is far from universal.  I'm
-talking to the git-buildpackage maintainers about gbp integration.
+talking to the git-buildpackage maintainers about gbp integration, so
+watch this space.
 
+xxx slide
 
 The other requirement of dgit is simply that the dgit branches are
 fast-forwarding.  So if your tools have made a rebasing branch, you
@@ -134,12 +138,13 @@ up.  They're are relevant to maintainers and non-maintainers:
 
 
 DMs currently need to email me a signed copy of their ssh key, in
-order to be able to push.
+order to be able to push.  This is because the project doesn't, right
+now, have a record of DMs' ssh keys.
 
 
-The dgit view does not generally include the package upload history.
-git-import-dscs can produce a git branch representing the upload
-history, but dgit doesn't run that itself.
+The dgit git history does not generally include the package upload
+history.  git-import-dscs can produce a git branch representing the
+upload history, but dgit doesn't run that itself.
 
 One could push such a branch to the archive with dgit push.  But, it
 seems to me that the git history structure ought to up to the