From f60090fe83fc884589dc1b3bb35a2c553b96b5e5 Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Thu, 13 Aug 2015 18:07:32 +0100 Subject: [PATCH] more talk --- talk.txt | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 103 insertions(+), 5 deletions(-) diff --git a/talk.txt b/talk.txt index 5e6bc20..24dc9b6 100644 --- a/talk.txt +++ b/talk.txt @@ -307,6 +307,8 @@ differently to the underlying tool, is pass some appropriate -I options, to exclude exactly and only the .git directory. +==== manpage clean slide + Finally, there is one compelling advantage of dgit's git-based approach. @@ -317,16 +319,112 @@ 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, ever again. +never have to fight a buggy clean target, in a strange package, ever +again. ==== Future plans slide -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. +I have a number of plans for the future, some of which I may even get +around to: + + +dgit can't currently upload to DELAYED queues, which makes it a bit +awkward for a fire-and-forget NMU. One way to implement this would be +to push to the suite branch but send the package upload to DELAYED. +But such an upload which was deleted by the maintainer still present +in the suite branch, and the changes might be resurrected by a future +dgit user. At the very least there should be a way for the maintainer +to revert a push which was accompanied by a DELAYED upload. + +The other implementation would have the pushed branch stashed away +somewhere and "revealed" only when it was ready, if it was still a +fast forward. That makes it tricker for someone else to build on it, +and is more work to implement, but it's probably better. + + +It would be easy for dgit to construct the NMUdiff and email it to the +BTS. Of course a maintainer can fetch your NMU easily with dgit, but +maybe the maintainer isn't using dgit (or, even, isn't using git at +all). + + +dgit push is slight more work than it needs to be when doing a +source-only upload. In this case there is not really any need for a +separate `dgit build-source' step. I think dgit push should make the +source package as well, since it easily can. + + +The dgit git server has most of the moving parts to become a +fairly-general-purpose git server with access control equivalent to +the Debian archive. In this role it could replace some uses of +Alioth, which is good because Alioth is doing too many other things. + +In particular, with the use of signed pushes, we could have +traceability of pushes, which makes a gitish packaging workflow more +practical - in particular, maintainers would not need to audit work +found on for-upload branches on the git server, before pushing the +code to the archive. (I suspect many maintainers already don't do +this as thoroughly as they should.) + + +dgit requires the suite branches to be fast forwarding. If you have a +workflow involving git rebase, you need to make a fake merge (ie, +merges made with git merge -s ours), at the tip of your branch, to +make it be a fast forward from the previous state of the suite branch. +And then when you want to work on the package again, you need to strip +that same fake merge. + +This can be done with raw git operations (git merge and git reset) +quite easily, but it's ugly. Also doing it by hand like this doesn't +provide many safety catches. + +I intend to provide some tooling which will help with this. + + +The final thing I can do myself is arrange for non-dgit uploads to be +automatically converted, and appended to the dgit suite branches on +the dgit git server. That would make the dgit history for any package +be more useful, starting with the first dgit-based upload. In +particular it would avoid the browse.dgit.debian.org view ever being +out of date. + + +There are also some things that I need help with. + +The documentation for how dgit works together with existing git +management tools is rather sparse. Ideally each git workflow tool +would explain how (or whether) it works with dgit. Tasks that should +be covered include how to incorporate changes made in an NMU into the +tool's favoured history format, and how to upgrade a package to a new +upstream version. + +That bug is request against git-dpm for new manpage covering these +topics, since I think the moving parts for git-dpm to work with dgit +are generally in place. + +And this leads on to the question of how to use git-buildpackage and +dgit together. As I say, I'm talking to the gbp maintainers. + + +And then there are a couple of exciting possibilities: + +Firstly, it would be very nice to have a way for a sponsee to provide +a dgitish git branch, which the sponsor could work with directly and +ultimately dgit push. + +Secondly, dgit is not just for Debian. Other distros currently using +only source packages have use it too. Read-only support doesn't +necessarily depend on specific support at the distro end. You can +already dgit fetch from ubuntu; I'd welcome patches for read-only +support for Mint, for example. + +dgit push support requires a suitably set up git server. I hear +rumours that Ubuntu might grow such a thing. -Instead, I'm going to open the talk up to questions now. +So that's most of what I have prepared. There's, of course, a lot +more detailed information in the manpages. -12 mins +I'm going to take questions now. -- 2.30.2