From 04b7f21320506d0d35332d119c853b4ac1b59552 Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Thu, 13 Aug 2015 01:23:09 +0100 Subject: [PATCH] wipxxx --- talk.txt | 35 +++++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/talk.txt b/talk.txt index 010c69b..9979ca7 100644 --- 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 -- 2.30.2