Niels Thykier writes ("Bug#1078016: git-debpush: want some option to print
workflow, if known"):
> Just adding my two (and half) cents on this as I was requesting this
> feature.
FTR, I think your aims are laudable. I hope we can help you build
the tool you want. I wouldn't be surprised if we wanted `dgit clone`
to invoke it :-), eventually.
The situation is complex, though, because there isn't really such a
thing as "the workflow for a package". Different people can interact
with the same package in different ways, depending on their views,
status, tooling preferences, team policy, and so on.
To give some examples:
* Some packages are "maintained in dgit". That means that as a
matter of policy, any maintainer upload must be done with dgit.
So whether to upload with dgit can be a decision for the uploader.
* When doing an NMU, or maintaining a downstream, one might use the
patches-applied view of the package (dgit fetch, or ad-hoc imported
apt source). In that case one can't do a new upstream version, but
one can do all other changes. One can then ignore the maintainer's
git (or quilt or whatever) workflows.
Note that the *same package* is typically available both as a
patches-applied view, and as a maintainer git branch possibly in a
tooling-specific format (eg, gbp pq unapplied).
So whether to use gbp pq or git-debrebase or whatever can
be a decision for the user/uploader, and cannot be inferred from
the contents of the package's filesystem tree, even if one has a
git repo. It can sometimes be inferred from git branch structure
and git tags. More on this later.
Your examples are illuminating:
> Tools and policies specific to this package:
>
> * `gbp dch` to generate the changelog.
> Documentation: `man:gbp-dch(1)
>
> * Automatic reformatting of packaging files via `debputy reformat`
> Documentation: `man:debputy(1)`
These are examples of maintainer (team) policies. They *must* be
followed when doing a maintainer or team upload. A kind NMUer will
follow them if it's not too inconvenient.
A user or other downstream may find this information about Debian's
practices useful, but it cannot be relied on (because NMUs) and the
downstream does not need to honour it (because they're outside the
bailiwick of the policy).
> * Upload via `dgit push-source` or `dgit push-built`
> Documentation: `man:dgit-maint-debrebease(7)
This is another team policy question, but it's more subtle.
dgit is explicitly designed to enable dgit-based uploads (eg, NMUs)
even when the maintainer doesn't know or care about dgit.
A non-maintainer dgit split git view upload (eg an NMU) is barely
detectable other than by use of dgit.
It is the opinion of the dgit maintainers that all uploads should be
done with dgit (where possible - eg right now security uploads can't
be).
So the two possible policies for a package are:
(i) it is the maintainer (team) policy that dgit should be used
(ii) dgit may be used at the uploader's discretion
One could try to infer the team policy by looking at the last upload.
But there are even mixed teams where some maintainers upload with dgit
and some without.
> * The packaging aims at zero-change rebuild compatibility with
> Debian `${RELEASE}-backports` and Ubuntu `$RELEASE_NAME`
>
> * The package is a part of the Python packaging team.
> Documentation: `https://....debian.org/python-policy/`
These also examples of team policies.
But they'r eones which must also be followed (or at least respected)
by NMUers.
> * The git workflow uses `dgit`'s `debrebase` and `quilt-mode=...`.
> Documentation: `man:dgit-maint-debrebease(7)
This information is specific to the *particular git history* of the
tree being worked with. I think it can usually be inferred from git
tags if dgit (or, soon, tag2upload) was used to upload.
But this information cannot be inferred from the tree contents.
It is useful for anyone working with the maintainer git view.
IMO non-Debian-experts ought not to work with the maintainer git view,
so we need to take some care about this. A tool which
unconditionally prints information which is relevant only to the
maintainer tree might print information which is confusing, or even
hazardous, to a Debian-naive user working with a patches-applied view
from `apt source && git add` or `dgit clone`.
OTOH, for a Debian expert this information is invaluable. If you are
familiar with the relevant tooling you can go right ahead and Do Stuff.
In particular, you know that it's safe to ignore the crazy gbp runes
which often the maintainer put in README.source a decade ago.
So ideally I think the branch status would be inferred from git tags.
git-debpush has some code to do this IIRC but I haven't looked at it
in a while and it may not be 100% reliable. I forget the details,
but I think Sean knows more.
> * The repo uses DEP-14 branch layout
> Documentation: `https://dep.debian.net/deps/dep14`
This is information about the specific repository. The repo itself is
named in Vcs-Git so the information could be in-tree if it's
understood as only applying to that specific tree.
Obviously a downstream, or even some team member's own fork on salsa,
might have a different layout.
> Obviously, I do not expect `dgit` to provide said tool nor all the
> information here. But the parts under `dgit`'s domain should be machine
> readable to enable us to write such a tool.
Yes. The quilt mode is machine-readable in the git tags.
> Ideally, I want this to be reverse engineer-able or machine discoverable
> rather than maintained by hand. That is because hand-maintained policies
> tend to get out of date as the team changes policies, while reverse
> engineering from the data looks at the current pattern. That said, I
> fully appreciate that some things are hard or even impossible to
> accurately reverse-engineer the common use-cases.
Right.
> I hope that explains the context and scope for what I want machine
> readable. You are the domain experts for `dgit`, so you are in the best
> position to say what can and cannot be reversed engineered vs. what must
> be a "manually maintained" policy.
This makes sense.
I'm afraid this reply may be a bit inchoate (and too long) but I hope
this it's helpful.
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.
