From: Ian Jackson Date: Mon, 10 Aug 2015 11:37:10 +0000 (+0100) Subject: wip X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ijackson/git?a=commitdiff_plain;h=3ce3082918a0f60f26c948f0935b1d9f4e274ccc;p=talk-2015-debconf-dgit.git wip --- diff --git a/NOTES-2 b/NOTES-2 index 0961b96..8245995 100644 --- a/NOTES-2 +++ b/NOTES-2 @@ -102,20 +102,3 @@ maintainer operations which change with dgit future plans -DELAYED uploads - -automatic sending of the NMU diff email - -source-only one step push - -use of the dgit git repo server (other branches and tags) for general -purpose work - -more assistance for use with raw git - - -work needed - -gbp integration - -sponsor queue diff --git a/talk.txt b/talk.txt index 7a5fe89..be4cb57 100644 --- a/talk.txt +++ b/talk.txt @@ -1,10 +1,20 @@ -Hi. I'm here to plug dgit, which is a tool (and infrastructure) for -treating the Debian archive like a git remote. +==== overview slide +> +> dgit - treat the archive as a git remote +> +> COLOUR 1 using dgit on other contributors' packages +> +> COLOUR 2 dgit for the Debian package maintainer +> +> Miscellany + + +Hi. I'm here to plug dgit, which is a system for treating the Debian +archive like a git remote. I'm going to talk for about 35 minutess and then I'll take questions. ----------------------------------------- When we work on Debian we take on different roles. The biggest difference is between the maintainer (or maintainers) of a package, @@ -13,11 +23,13 @@ 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. +users, and so on. Maintainers, please be patient - I'll get to you. -The point of dgit is that it lets you treat the archive as if it were -a git repository. +==== manpage slide + +The point of dgit is that it lets everyone treat the archive as if it +were a git repository. You can dgit clone any package, in any suite in the archive (so, for example, sid or experimental) and you will get a git tree which is @@ -26,19 +38,22 @@ exactly the same as dpkg-source -x. You can then work on the package in git, the way you would work in git with any other project. In particular, you can: - * commit on your local branch + * commit locally * cherry pick changes from other branches * git reset, git clean * git rebase -i to polish a more complex set of changes into a patch queue If you want so share your work-in-progress with others, you can git -push your branch anywhere where they will be able to fetch it. +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 @@ -48,29 +63,29 @@ format. 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 -package is using a quilty source format, you should not touch -debian/patches; dgit will take care of updating the quilt patch stack. +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. Unless the maintainer uses dgit, the history you see in dgit will not be the maintainer's history. This is because maintainers' git -branches are often not identical to the source packages in the -archive. +branches often differ from the source packages in the archive. -And, when dgit has to synthesise a git history because the maintainer -is not using dgit, the history you see in dgit will have a very basic -branch and commit structure, rather than representing the package's -actual history. +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 +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. -For the reasons I've explained, other 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. +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. But it's in your own interests, too: @@ -87,59 +102,63 @@ If you use dgit push, you get an extra check that the source package you are uploading is exactly the same as your git HEAD. This can save you some dsc-based checks. -And, of course, non-maintainer dgit users will thank you. +And, as I say, non-maintainer dgit users will thank you. +==== structure slide +> with push requirement clearer + dgit push imposes only two requirements on your git trees. These stem -directly from the need for the dgit view of package to be identical to -the package as found in the archive. The dgit view of every package -needs to uniformly and directly useable. +directly from dgit's design goals. -The first, and 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'.) +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'.) For all native packages, and for users of git-dpm and raw git, this is already the interchange format. These maintainers can start using dgit right away. Please do! -For git-buildpackage users, 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. +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. I'm talking to the git-buildpackage +maintainers about gbp integration. -I mentioned that there were two requirements. The other is simply -that the dgit branch (one for each suite) is fast-forwarding. So if -you (or your workflow tool) generated a rebasing branch, you may need -to do something like +The other requirement of dgit is simply that the dgit branches are +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 cookied +before pushing. I'm intending to provide some rather more cooked way to do this but I have decided the exact shape yet. ----------------------------------------- +==== structure diagram +> There are a few other things I ought to cover, since they often come -up: +up. They're are relevant to maintainers and others: + + +DMs currently need to email a signed copy of their ssh key, in order +to be able to push. -The dgit view of the archive does not include the package upload -history. It is possible to use git-import-dscs to produce a git -branch representing the upload history, but dgit does not do this -itself. +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 does do that itself. -There is nothing stopping anyone from pushing such a branch to the -archive with dgit push. But, it seems to me that the git history -structure ought to up to the maintainer, and if the maintainer chooses -to use dgit, normally the maintainers's existing git history is more -useful and interesting. +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 +maintainer, and if the maintainer chooses to use dgit, the +maintainers's existing git history is probably better. -When using dgit, it is normally best to use one of dgit's build -operations to build the package. This is mainly because most other -build tools by default remove .gitignore when generating the source -package. dgit requires that the source package and git tree are the +It is normally best to use one of dgit's build operations to build for +upload. This is mainly because most other tools remove .gitignore by +default. dgit requires that the source package and git tree are the same, so if your git tree has .gitignore in it, your source package should too. @@ -151,35 +170,43 @@ package's clean target entirely. Some maintainers' source packages contain files not in their git -branches: most commonly, autotools output. Because the point of dgit -is to provide a git view of what's actually in the archive, this does -not work with dgit. - -But nowadays most people seem to recommend that the package build -should rerun autotools and regenerate these files, anyway. If you do -this, then neither your git tree nor your source package contain the -autotools output and all is well. - -Alternatively, you can commit the autotools output to git (and resolve -any conflicts by simply rerunning autotools), or maintain a separate -post-autotools git branch. - - - - - -The point, of course, of using - - - - - - - - - - - - defer talking about - - +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. + +But nowadays most people recommend that the package build should +always rerun autotools, anyway. If you do that, then neither your git +tree nor your source package need contain the autotools output and all +is well. + +Alternatively, you can commit the autotools output to git. + + +==== Future plans slide +> DELAYED uploads +> +> automatic sending of the NMU diff email +> +> source-only one step push +> +> use of the dgit git repo server (other branches and tags) for general +> purpose work +> +> more assistance for use with raw git +> +> automatic tracking of uploads into the dgit suite branches +> +> +> help needed +> +> better workflow documentation for integration with existing git tools +> +> better gbp integration +> +> sponsor queue + + +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. + +Instead, I'm going to open the talk up to questions now.