more talk

[talk-2015-debconf-dgit.git] / talk.txt

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
 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
 
 
 ==== 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
  * 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
 
 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
 
 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
 
 
 ==== 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
 
 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
 ==== 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:
 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
 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
 
 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
 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
 
 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
 
 
 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
 
 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