From 9f79541d3913bace58e10aaeb2b84a7147bb984d Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Mon, 10 Aug 2015 11:29:17 +0100 Subject: [PATCH] wip --- NOTES-2 | 20 ++++++ talk.txt | 195 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 215 insertions(+) create mode 100644 talk.txt diff --git a/NOTES-2 b/NOTES-2 index 7f836e0..2add7d7 100644 --- a/NOTES-2 +++ b/NOTES-2 @@ -97,3 +97,23 @@ maintainer operations which change with dgit 3.0 (quilt) gbp YES ??? + + + +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 + + +work needed + +gbp integration + +sponsor queue diff --git a/talk.txt b/talk.txt new file mode 100644 index 0000000..43bebc3 --- /dev/null +++ b/talk.txt @@ -0,0 +1,195 @@ + +Hi. I'm here to plug dgit, which is a tool (and infrastructure) for +treating the Debian archive something 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, +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 +(eg, transitions, reproducible builds), bug squashers, and so on. + + +The point of dgit is that it lets you 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 +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: + + * commit on your local branch + * cherry pick + * git reset, git clean + * git-rebase -i to polish your changes + +If you want so share your work-in-progress with others, you can git +push the branch anywhere where they will be able to fetch it. + +If you are a DD (or a DM for the package) you can also dgit push the +package. (Currently you still need to do a source package build.) + + +Because dgit knows that your git tree is canonical, it can help you +work around strangely behaved package clean targets: you can instruct +dgit to use git clean rather than running the package's clean target. + + +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 use of particular +source formats. + + +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, the way that you would for any project which is +using 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. + +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. + +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. + + +---------------------------------------- + +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. + +But it's in your own interests, too: + +If you use dgit, you will be able to directly merge and/or cherry-pick +NMUs, patches proposed via pull-request emails, and so on: Because, in +this case, the dgit-using contributor will have based their work on +your own history. + +Using dgit for your maintainer uploads will put your own history on +browse.dgit.debian.org, rather than showing dgit's stub history (which +can also be out of date). + +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. + + +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. + +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'.) + +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. + + +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 + git merge -s ours dgit/sid +before pushing. I'm intending to provide some rather more cookied +way to do this but I have decided the exact shape yet. + + +---------------------------------------- + +There are a few other things I ought to cover, since they often come +up: + + +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. + +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 is +choosing to use dgit, normally the maintainers's existing git history +is more useful and interesting. + + +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 +same, so if your git tree has .gitignore in it, your source package +should too. + + +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. + + + + + + + cannot +use such a git branch + +people have different contents in their git branches to in their + + + +To use dgit push, there are some things you may have to do +differently. + + + + +The point, of course, of using + + + + + + + + + + + + defer talking about + + -- 2.30.2