Package: git-phab Version: 1.0.0-2 Severity: serious Hi, Andrew.
Thanks for your clear explanations on IRC yesterday. As you know this .dsc file has a Dgit field referring to a commit not available fromk the dgit repos. As a result dgit clone and dgit fetch of this package currently fail: $ dgit fetch canonical suite name for unstable is sid fetching from suite sid downloading http://ftp.debian.org/debian//pool/main/g/git-phab/git-phab_1.0.0-2.dsc... last upload to archive specified git hash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 20204 100 20204 0 0 98505 0 --:--:-- --:--:-- --:--:-- 98556 fatal: Not a valid commit name f915b614a869a0f3610c2fc76d6105da2e28b306 dgit: failed command: git merge-base f915b614a869a0f3610c2fc76d6105da2e28b306 70495969a699db8803fcb8921a3cff2f44f348e2 dgit: subprocess failed with error exit status 128 $ You told me on IRC this situation was arranged by your manual intervention. Specifically, you were trying to get dgit to permit a non-fast-forward push, which dgit didn't want to do. I explained that I thought dgit was correct to refuse. You've told me you're going to stop using dgit. That's fine, of course, but the current state of the dgit-repos and the archive are not consistent. Even if a new version is uploaded, anyone doing archaeology will probably find that their attempts to use `dgit import-dsc' on git-phab 1.0.0-2 will fail. You requested that I rewind history on the dgit git server, or delete the git-phab repository there. I have declined to do this on the grounds that this history should continue to be available to dgit users; that deleting or rewinding there is contrary to the design and therefore to the promises made to downstreams, so there may exist downstreams or mirrors which would break or signal an exception; and that either of these proposals would cause `dgit import-dsc' to fail on historical git-phab .dscs (from snapshot.d.o). Having slept on it, I still think that is the right decision. I think the best way to sort this out is for me to do a dgit-based no-change NMU, of a branch which is descended from the commit named in 1.0.0-2's .dsc as well as from 1.0.0-1. This will ensure that the commits referenced by all previously-uploaded git-phab .dsc's will be findable. For this to work it is not necessary for my NMU to actually make it to the archive. So unless you object I intend to make this NMU to DELAYED-14. You may then use dcut, or upload a later version. If you object before I actually make the NMU I can arrange to simulate the effect of my uploading to DELAYED-14 and you running dcut, by making my NMU and pushing it only to the dgit git server but arranging for the archive upload to be discarded. That would save you the effort of running dcut. The overall change in these scenarios is only to the contents of the dgit git server, not to the archive (unless the NMU is allowed to make it through DELAYED). I should mention that in these scenarios, if another dgit user should make an NMU for any reason before your own next upload, they would get the version from the dgit git server as the most recent version. The sole effect of this from your point of view would be that they would reintroduce the changelog entry for my deleted NMU, so this should be of no real concern. If you object even to what I propose above I'm afraid you will need to escalate the matter. I think your correct escalation path is the TC, although frankly the TC are not likely to make any decision with reasonable promptness. I'm know this mail is not what you would like to hear and I appreciate that it's likely to make you angry. I'm sorry about that. I intend to use the version number 1.0.0-2+nmu0dgit but I'm happy to use a different version number if you prefer - just say. Thanks for your attention. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
