From 14af25cb03a17f3c12ee5ae347203ac59b602e09 Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Mon, 10 Aug 2015 13:19:56 +0100 Subject: [PATCH] wip, slides ready to make ? --- talk.txt | 57 +++++++++++++++++++++++++++----------------------------- 1 file changed, 27 insertions(+), 30 deletions(-) diff --git a/talk.txt b/talk.txt index be4cb57..65eb184 100644 --- a/talk.txt +++ b/talk.txt @@ -26,7 +26,7 @@ like transitions and reproducible builds, bug squashers, downstreams, users, and so on. Maintainers, please be patient - I'll get to you. -==== manpage slide +==== data flow slide The point of dgit is that it lets everyone treat the archive as if it were a git repository. @@ -50,16 +50,7 @@ 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 -define a branch structure. Nor does it require a particular source -format. - +==== NMU linear history slide The dgit history structure is up to the maintainer. If you are doing a straightforward NMU you should produce a well-structured linear @@ -67,6 +58,8 @@ 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. +==== 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. @@ -76,16 +69,15 @@ 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. + +==== history comparison slide + 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. +to use dgit push. They will then be able to see, and directly work +with, your own history. But it's in your own interests, too: @@ -105,8 +97,14 @@ save you some dsc-based checks. And, as I say, non-maintainer dgit users will thank you. -==== structure slide -> with push requirement clearer +==== data flow slide with EQUAL and FF + +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 a particular source +format. + dgit push imposes only two requirements on your git trees. These stem directly from dgit's design goals. @@ -132,14 +130,13 @@ 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 cooked -way to do this but I have decided the exact shape yet. +way to do this but I haven't decided the exact shape yet. -==== structure diagram -> +==== data flow slide There are a few other things I ought to cover, since they often come -up. They're are relevant to maintainers and others: +up. They're are relevant to maintainers and non-maintainers: DMs currently need to email a signed copy of their ssh key, in order @@ -171,8 +168,7 @@ package's clean target entirely. Some maintainers' source packages contain files not in their git 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. +with dgit's purpose of providing a git view of the archive. But nowadays most people recommend that the package build should always rerun autotools, anyway. If you do that, then neither your git @@ -187,19 +183,20 @@ Alternatively, you can commit the autotools output to git. > > automatic sending of the NMU diff email > -> source-only one step push +> one step source-only push/upload > > use of the dgit git repo server (other branches and tags) for general > purpose work > -> more assistance for use with raw git +> better tooling assistance for use with raw git-rebase > -> automatic tracking of uploads into the dgit suite branches +> automatic mirroring into the dgit git branches of non-dgit uploads > > > help needed > -> better workflow documentation for integration with existing git tools +> better workflow documentation for integration with existing git +> tools (esp. re NMU integration and new upstream version handling). > > better gbp integration > @@ -207,6 +204,6 @@ Alternatively, you can commit the autotools output to git. 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. +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. -- 2.30.2