wip, slides ready to make ?

diff --git a/talk.txt b/talk.txt
index be4cb57c7b0aa8fb39e6cbf0875fb47e3130c288..65eb184ae8367af8af5c085d71febd2ae6d8ea17 100644 (file)
--- a/talk.txt
+++ b/talk.txt
@@ -26,7 +26,7 @@ like transitions and reproducible builds, bug squashers, downstreams,
 users, and so on.  Maintainers, please be patient - I'll get to you.
 
 
-==== manpage slide
+==== data flow slide
 
 The point of dgit is that it lets everyone treat the archive as if it
 were a git repository.
@@ -50,16 +50,7 @@ push your branch anywhere suitable, so they can fetch it.
 If you have the right authority you can also dgit push, to upload
 (after doing a build).
 
-
-==== structure slide
-> include git-dpm, git, etc.
-
-dgit is not a replacement for existing git packaging tools; it's
-intended to complement them.  So (unlike git-dpm) dgit does not define
-a git history structure, and (unlike git-buildpackage) it does not
-define a branch structure.  Nor does it require a particular source
-format.
-
+==== NMU linear history slide
 
 The dgit history structure is up to the maintainer.  If you are doing
 a straightforward NMU you should produce a well-structured linear
@@ -67,6 +58,8 @@ sequence of commits, as you would for any git upstream.  If the source
 package is `3.0 (quilt)', you should not 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.
@@ -76,16 +69,15 @@ dgit will then have a very basic branch and commit structure, rather
 than representing the package's actual history.
 
 
-==== history comparison slide
-> you use dgit
-> you don't use dgit
-
 Which brings me onto the other side of this talk: dgit for
 maintainers.
 
+
+==== history comparison slide
+
 For the reasons I've explained, downstream dgit users would like you
-to use dgit for your maintainer uploads.  They will then be able to
-see, and directly work with, your own history.
+to use dgit push.  They will then be able to see, and directly work
+with, your own history.
 
 But it's in your own interests, too:
 
@@ -105,8 +97,14 @@ save you some dsc-based checks.
 And, as I say, non-maintainer dgit users will thank you.
 
 
-==== structure slide
-> with push requirement clearer
+==== data flow slide with EQUAL and FF
+
+dgit is not a replacement for existing git packaging tools; it's
+intended to complement them.  So (unlike git-dpm) dgit does not define
+a git history structure, and (unlike git-buildpackage) it does not
+define a branch structure.  Nor does it require a particular source
+format.
+
 
 dgit push imposes only two requirements on your git trees.  These stem
 directly from dgit's design goals.
@@ -132,14 +130,13 @@ fast-forwarding.  So if your tools have made a rebasing branch, you
 may need to do something like
    git merge -s ours dgit/sid
 before pushing.  I'm intending to provide some rather more cooked
-way to do this but I have decided the exact shape yet.
+way to do this but I haven't decided the exact shape yet.
 
 
-==== structure diagram
-> 
+==== data flow slide
 
 There are a few other things I ought to cover, since they often come
-up.  They're are relevant to maintainers and others:
+up.  They're are relevant to maintainers and non-maintainers:
 
 
 DMs currently need to email a signed copy of their ssh key, in order
@@ -171,8 +168,7 @@ package's clean target entirely.
 
 Some maintainers' source packages contain files not in their git
 branches: most commonly, autotools output.  This is not compatible
-with dgit's purpose, namely to provide a git view of what's actually
-in the archive.
+with dgit's purpose of providing a git view of the archive.
 
 But nowadays most people recommend that the package build should
 always rerun autotools, anyway.  If you do that, then neither your git
@@ -187,19 +183,20 @@ Alternatively, you can commit the autotools output to git.
 > 
 > automatic sending of the NMU diff email
 > 
-> source-only one step push
+> one step source-only push/upload
 > 
 > use of the dgit git repo server (other branches and tags) for general
 > purpose work
 > 
-> more assistance for use with raw git
+> better tooling assistance for use with raw git-rebase
 > 
-> automatic tracking of uploads into the dgit suite branches
+> automatic mirroring into the dgit git branches of non-dgit uploads
 > 
 > 
 > help needed
 > 
-> better workflow documentation for integration with existing git tools
+> better workflow documentation for integration with existing git
+> tools (esp. re NMU integration and new upstream version handling).
 > 
 > better gbp integration
 > 
@@ -207,6 +204,6 @@ Alternatively, you can commit the autotools output to git.
 
 
 I have a number of plans for the future, some of which I need help
-with.  I don't have time I'm afraid to go through them now.
+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.