Fabio Fantoni:
Il 05/08/2024 03:14, Andrey Rakhmatullin ha scritto:
[...]
Thanks for reply, what I mean is precisely a standard field that points
to a file, inside the package or even an url as already explained can be
very useful in most cases) that contains all the useful information for
contributing to that package, including the one you mention. even if
everyone applied DEP-14 and DEP-18 there would be some differences that
could be useful to know in a simple and immediate way. and I think this
is even more useful with the current situation and also very useful in
case of any future migrations to more standardized systems.
currently you find such information from a simple search and/or looking
a bit in the source, in the possible git in a few minutes only in part
of cases, in many other cases instead it requires more time, the
possible contact of the maintainer, attempts (and then eventually feel
that it would be better to "improve" your contributions using other
methods).
a single standard field (to be added optionally) and adding links to
that file or url in the tracker (if present) I think would bring
advantages and save time for both contributors and maintainers in many
cases (when used)
If we go down this route, could we consider making it machine readable
(in parallel with human readable)[0]. For people doing drive-by
nmu/patches across many packages, having to manual open link and read
policies can often take considerable time. It is the small things really
like:
* Does this package use `gbp dch` (or some other mechanisms) to
generate the changelog OR should I include a changelog entry with my
patch.
* Does this package use some form of automatic formatting that I should
apply when I do my changes (if `wrap-and-sort`, then which options)?
* Does the maintainer prefer MR via salsa or BTS with patches for when
I want to submit my changes for review. (I get this is the DEP-18
thread and the answer should be "MR via salsa", but then DEP-18 is
opt-in, which means it might not be "MR via salsa" after all)
* Does the maintainer prefer dgit and if so, which of its 5+ different
documented workflows should I follow?
(Like how does it manage patches git-wise)
* Etc.
And yet we do not have good answers for these kind of questions in an
automated fashion.
I am happy to work on the client side of this problem. I already took a
stab at something similar (see [1], currently stuck on getting a single
source of truth data source), so it would fit into the work I am doing
anyway.
Best regards,
Niels
[0]: I mean a dedicated `JSON` or `YAML` file in parallel to the human
policy. Shenanigans like parsing special statements from formats aimed
at humans do not really cut it in my book.
[1]: https://salsa.debian.org/debian/debputy/-/merge_requests/37
