Package: git-debpush Version: 13.13 git-debpush notices if your suite has changed since the last upload and complains. I'm not sure this complaint is warranted. If it *is* warranted, maybe dgit should have it too.
Background - the no-good UNRELEASED changelog convention: The possibility of this mistake arises because of the (IMO broken) "UNREELASED" convention in changelogs. Using UNRELEASED this way, (rather than an unfinalised changelog entry) deletes the target suite information from the changelog. Then dch must restore it but it doesn't have all the information. I think UNRELEASED was invented because some tool(s) didn't understand unfinalised changelogs, so someone invented the same thing again but worse. UNRELEASED's sole advantage is that it can be parsed by bad changelog parsers. (The date in it is often a hindrance.) Unfortunatley the UNRELEASED convention is widespread (and not all tooling supports unfinalised chagnelogs very well). But, I think the right answer to this possible source of human error is to use unfinlised changelogs instead (and play whack-a-mole with tooling). (Or to put something like UNRELEASED-unstable into the changelog.) I use unfinalised changelogs, so that's what we've been doing in the dgit team. With our workflow, this mistake cannot arise, so there is never any need to confirm a change of suite. A change of suite in the changelog was always done deliberately, by changing the suite in changelog from one real suite into another. git-debpush pickiness: git-debpush can easily do this check because it's digging into history anyway to try to find out which quilt mode to use. dgit would maybe have to do something similar if we wanted it to check this. But git-debpush is trying to be less picky than dgit. I think this includes not just trying to avoid conversion failures at the t2u service, but also being picky about things that can be detected synchronously. It seems odd that we have put a check in git-debpush which mitigates a risk that existing upload tooling also fails to mitigate, and for which there are other mitigations, at least some of which can be adopted immediately. Compaarison with dgit: dgit has a --new option which seems to do the same thing, but is actually for something different. dgit insisting on --new won't stop you accidentally uploading the experimental branch to sid. I think dgit's --new is wrong and have filed #1107551 about that. Tenative conclusion: This check should be simply removed from git-debpush. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
