On Wed, 14 Aug 2024 08:28:08 +0800 Sean Whitton
<spwhit...@spwhitton.name> wrote:
Hello,
On Tue 13 Aug 2024 at 10:25pm +01, Ian Jackson wrote:
> I think we need to be a little careful about the distinctions between
>
> 1. dgit quilt mode
> 2. git branch and tree format
> 3. workflow
>
> These go from least to most specific. The user probably needs to know
> 2, not 1 or 3. For example, what if the package is maintained in
> git-debrebase ?
>
> We lack a good name for 2 but maybe we could fudge it and say
> "workflow" when we mean "workflow indistinguishability class under
> external examination".
Yeah, good, we do indeed want to provide (2), and (3) is a matter for
README.source. So, perhaps this thing ought to be printing "unknown" if
there's the possibility of gdr, for example.
--
Sean Whitton
Hi
Just adding my two (and half) cents on this as I was requesting this
feature.
I want all of this to be machine readable if it is something a user or
packager need to know about. For me, it is only a question of how to
expose this.
Ideally, we would have a single well-defined workflow. However, we, as a
project, have continuously failed to agree on such a workflow and I
doubt we will soon. Therefore, in my "fallback ideal" world, I want to
have tool assistance here.
It should be something like:
$ git clone .../my-project
$ cd my-project
$ explain-packaging-workflow
Tools and policies specific to this package:
* `gbp dch` to generate the changelog.
Documentation: `man:gbp-dch(1)
* Upload via `dgit push-source` or `dgit push-built`
Documentation: `man:dgit-maint-debrebease(7)
* The git workflow uses `dgit`'s `debrebase` and `quilt-mode=...`.
Documentation: `man:dgit-maint-debrebease(7)
* The repo uses DEP-14 branch layout
Documentation: `https://dep.debian.net/deps/dep14`
* Automatic reformatting of packaging files via `debputy reformat`
Documentation: `man:debputy(1)`
* 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/`
...
With the goal of making the "common" cases for `debian/README.source`
obsolete. Then add UX features like highlighting based which rules the
packager has marked as "known" vs. rules they do not know, etc.
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.
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.
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.
Best regards,
Niels
