wip

diff --git a/talk.txt b/talk.txt
index 73cf7cf81fab0acbd4fabfd763b203dcfee7a254..2bcbad257d4cf6694661d2c74501cc25fa9a85d4 100644 (file)
--- a/talk.txt
+++ b/talk.txt
@@ -5,10 +5,9 @@ Hi.
 ===== context slide
 
 Sean Whitton and I are here to present a new git workflow tool for
-Debian packaging.  It's primarily intended for Debian package
-maintainers.  It's an alternative to gbp pq and to git-dpm.
+Debian packaging.
 
-Before I get tell you all about it I need to show where it fits into
+Before I tell you all about it I need to show where it fits into
 the ecosystem of Debian package management software.  On this slide we
 have you, the maintainer, on the left.  On the right we have the
 Debian repositories.
@@ -19,6 +18,10 @@ it!  But, that's not actually what I am here to talk about today.
 git-debrebase does not need dgit, and dgit does not need
 git-debrebase.
 
+git-debrebase is an alternative to gbp pq and to git-dpm, and to
+other tools in the same kind of area like gitkpkg.  And, of course,
+it's an alternative to using raw quilt.
+
 git-debrebase is a tool to help manage your git branch containing the
 Debian version of a package you maintain.  git-debrebase helps you
 maintain a useful git branch with the contents you need (for building
@@ -26,7 +29,19 @@ and uploading).
 
 It maintains your Debian delta queue - that is, that is, the changes
 you make, for Debian, to the upstream parts of the package - as a
-series of commits.
+series of commits.  It's primarily intended for Debian package
+maintainers, although you could use it outside of or alongside Debian.
+
+git-debrebase does not deal with building at all.  You use whatever
+your existing build tools are.
+
+Nor does git-debrebase deal with source packages or orig tarballs.  It
+does not do uploads.  Of course when you actually upload to Debian you
+need to produce a source package; usually, this would be done
+automatically for you by dgit push-source.
+
+Of course you can share your git branch on a service like salsa,
+without building or uploading.
 
 ===== usp slide 1
 
@@ -35,54 +50,66 @@ the whole package all together.  The experience is very like using
 plain git-rebase to edit a topic branch.  Delta queue editing can be
 done at any time, interleaved with packaging work.
 
-As you make new commits, you may make commits to upstream files, and
-commits to packaging, in any order.  So you can just git-cherry-pick
-from upstream.  You can make fixup commits, and use the git-rebase
-autosquash syntax to have them automatically folded in by the next
-rebase.  If you wish, you may make "mixed" commits containing both
-changes to upstream files and changes to packaging files.
-
 As far as I know there are no other tools that offer these features.
 Both gbp pq and git-dpm require you to switch to a separate view in
 order to edit the delta queue.  Some tools have specific functions for
-cherry-pick, but with none of them you can just cherry pick or git-am
-onto your current HEAD.
+cherry-pick, but with none of them you can just use plain git cherry
+pick or git-am onto your usual branch.  With git-debrebase, you can
+just edit the code and commit it, with git, in the completely usual
+way.
+
+Specifically, at any point, you may make commits to upstream files,
+and commits to packaging, in any order.  So you can just
+git-cherry-pick from upstream.  You can make fixup commits, and use
+the git-rebase autosquash syntax to have them automatically folded in
+by the next rebase.  If you wish, you may make "mixed" commits
+containing both changes to upstream files and changes to packaging
+files.
 
 Of course you can always directly edit the source if you use a plain
 git merge workflow and non-quilt source package - for example, as
 described in the dgit-maint-merge tutorial manpage.  But of course
 that does not maintain the Debian delta as a broken-down series.
+Supporting you maintaining such a delta queue is what git-rebase is
+for.
 
 Also, unlike git-dpm and some other tools, git-debrebase has no
-in-tree metadata, so it can't get out of date or be desynchronised.
+in-tree metadata, so it can't get out of date or be desynchronised,
+or need any manual changing or fixup.
 
 ===== usp slide 2
 
-Unlike with gbp pq and git-dpm, there is no need to ever switch
-branches.  git-debrebase only uses one branch to handle all for your
-Debian work.  (Usually you will have an upstream branch as well of
-course, and if you are working in multiple Debian releases, backports
-for example, you will have branches for those.)
+As I said, unlike with gbp pq and git-dpm, there is no need to ever
+switch branches.  git-debrebase only uses one branch to handle all for
+your Debian work.
+
+Of course usually you will have an upstream remote tracking branch as
+well.  And if you are working in multiple Debian releases, backports
+for example, you will have branches for those.  But it's only one
+branch for each line of Debian development, and no temporary branches
+or alternative views.
 
-Yowr working tree is always immediately buildable with
-dpkg-buildpackage.  And it is never made dirty by git-debrebase or any
-of the other tooling.  Because your working tree always has the delta
-queue applied, it is never dirtied by patch application.  Because
-there is no metadata, you can never get a metadata conflict.
+With git-debrebase, yowr working tree is always immediately buildable
+with dpkg-buildpackage (or whatever other build tool you prefer).  And
+it is never made dirty by git-debrebase or any of the other tooling:
+Because your working tree always has the delta queue applied, it is
+never dirtied by patch application.  Because there is no metadata, you
+can never get a metadata conflict.
 
 Because git-debrebase treats the quilt patches in debian/patches/ as
 an output, and handles them entirely automatically, your tree is never
 dirtied by the generation of patches.  And you never need to read any
 diffs of diffs.
 
+
 ===== usp slide 3
 
-And, my last slide of non-bugs:
+And, the final part of my plug:
 
-git-blame, and git-log on a file, work entirely properly.  For
-example, if you do git-log on a file from upstream which was changed
-in the Debian delta queue, git-log will show the Debian delta queue
-commits, preceded by the upstream history.
+With git-debrebase, git-blame, and git-log on a file, work entirely
+properly.  For example, if you do git-log on a file from upstream
+which was changed in the Debian delta queue, git-log will show the
+Debian delta queue commits, preceded by the upstream history.
 
 If you run git-blame you will see a correct indication of which
 upstream and/or delta queue commits introduced each line.  Or, for a
@@ -90,18 +117,19 @@ file in the debian directory, you will see a correct reporting of
 which commits in the package's packaging history introduced each line.
 
 With git-debrebase, you never need to use the quilt program.  You can
-mostly ignore the 3.0 quilt source format.  (Unfortunately you will
-still get trouble if you make changes in git which 3.0 quilt cannot
-represent).
+mostly ignore the 3.0 quilt source format.  Unfortunately it is not
+possible to paper over the cracks completely: you will still get
+trouble if you make changes in git which 3.0 quilt cannot represent.
 
-When you use git-debrebase with 3.0 quilt, the quilt output is always
-perfect and pretty, just as other people consuming .dscs have come to
-expect.
+On the other hand, when you use git-debrebase with 3.0 quilt, the
+generated 3.0 quilt source package is perfect pretty, with your delta
+queue commits converted nicely into pathes - just as other people
+consuming .dscs have come to expect.
 
 And finally: of course, git-debrebase is compatible with dgit.  You do
-not need to pass any quilt mode option.  And, you always can upload
-right away.  All necessary bureaucracy is done automatically by dgit
-push-source.
+not need to pass any quilt mode option to dgit.  And, you always can
+upload right away.  All necessary bureaucracy is done automatically by
+dgit push-source.
 
 ===== demo