wipxxx

diff --git a/talk.txt b/talk.txt
index 010c69b95f5a7b24e0a5efb89fd70fafdaefcb03..9979ca7800adc1c8b5819c7658ae46536784e990 100644 (file)
--- a/talk.txt
+++ b/talk.txt
@@ -15,7 +15,8 @@ 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, 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.
+like transitions and reproducible builds, and so on.  Maintainers,
+please be patient - I'll get to you later
 
 
 ==== manpage slide
@@ -40,7 +41,7 @@ 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
+ * all the other usual gitish stuff
 
 If you have the right authority you can also dgit push, to upload.
 That is, a DD can dgit push any package; a DM can dgit push the
@@ -52,12 +53,14 @@ provide some helpful build rune wrappers (more about that later).
 
 
 If you don't want to, or can't, upload to Debian, but do want so share
-your work-in-progress with other people, you can git push your dgit
+your work with other people, you can git push your dgit
 branch anywhere suitable, so they can fetch it.  So, for example, you
 could share your branch with your sponsor, who could then approve it
 by running dgit push.  dgit's branches are ordinary git branches for
 this purpose.
 
+dnstrxxx
+
 ==== data flow slide
 
 Behind the scenes, dgit works by providing a set of git repositories
@@ -66,7 +69,7 @@ in parallel to the existing archive.
 Every dgit push is actually two underlying operations: the first is a
 git tag and push, to the dgit git server.  The second is a
 conventional package upload - with a wrinkle: the .dsc of an upload
-done with dgit contains the git commit hash that was pushed.
+done with dgit contains xxxfld the git commit hash that was pushed.
 
 Likewise, fetch and clone combine information from the archive and the
 git history.  If the most recent upload was done with dgit, the commit
@@ -75,12 +78,12 @@ present it to you.  If the most recent upload was not done with dgit,
 dgit imports the source package into git - and stitches it into the
 existing dgit history, if there is one.
 
-You do need to dgit branches a bit specially is if you need to build
+You do need to treat dgit git branches a bit specially is if you need to build
 source pacakges (for upload, for example).  In this case dgit needs
 the .orig tarballs for your source package.  If you are not doing a
 new upstream version, dgit fetch will get the relevant .origs for you.
-If you are, then presumably you have obtained them as part of
-preparing your package, or can build them easily.
+If you are dnxxx, then presumably you have obtained them as part of
+preparing your package, or you can build them easily.
 
 
 ==== NMU linear history slide
@@ -99,7 +102,8 @@ If the source package is `3.0 (quilt)', you shouldn't touch
 debian/patches; dgit will take care of that for you.  This is the
 other reason why you should provide a tidy linear patch series: if the
 maintainer likes quilt and is not using dgit, your changes will be
-automatically presented to them in a fairly plausible format.
+automatically presented to them in a fairly plausible format like they
+would exp xxx
 
 An ordinary NMUer should not normally update a patch in the quilt
 stack directly.  Ie, an NMUer shouldn't squash their changes into an
@@ -158,7 +162,7 @@ What dgit does is provide a way for you to publish a history which
 users can rely on actually corresponding to the archive, and use
 immediately without special knowledge.
 
-But it's in your own interest to upload with dgit, too:
+But it's in your own selfish interest to upload with dgit, too:
 
 If you use dgit, you will be able to directly merge NMUs, patches
 proposed via pull-request emails, and so on: Because, in this case,
@@ -202,7 +206,7 @@ directly from dgit's objectives.
 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 directory'.)
+packaging branch without .pc directory' xxx.)
 
 For all native packages, and for users of git-dpm and raw git, this is
 already the interchange format.  These maintainers can start using
@@ -238,7 +242,7 @@ of DMs' ssh keys.
 
 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.
+upload history, but dgit doesn't run that itself.  why noy xxx
 
 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
@@ -253,6 +257,8 @@ same, so if your git tree has .gitignore in it, your source package
 should too.
 
 
+an adv co xxx
+
 Many packages have strangely-behaved or plain buggy clean targets.
 Because dgit knows that your git tree is canonical, it can help work
 around this: you can tell dgit to use git-clean instead, avoiding the
@@ -260,8 +266,10 @@ 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, again.
+never have to fight a buggy clean target, in a strange package, ever again.
+
 
+wrink n
 
 Some source packages contain files not in the maintainers' git
 branches, and which are needed to build: most commonly, autotools
@@ -282,3 +290,6 @@ 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.
 
 Instead, I'm going to open the talk up to questions now.
+
+
+12 mins