I think such a GR would be a collosal waste of time. This issue is
not important enough. In particular, because the consensus is *not*
GR's can be man made a collosal waste of time.
Well, a GR can be quick and it would help to know where people stand
instead of having a few vocal people decide for everyone. I think we
should impose the use of "dh" for bullseye (with an exception for teams
with more then 50 packages), but I honestly don't know how much this
opinion is shared.
I followed the discussion closely but i don't get some points. I assume
that "dh" is here to stay - so in that case new packages should be done
with "dh", older packages should be converted. There might be some
packages which are not worth the additional work. Just leave a note why
and everyone is happy. So a GR would be a appr. tool to solve this
endless discussion fast.
last "technical" GR was for systemd in 2014. We are in a project where
it is very hard to be heard because you can only participate in endless
debates.
I for myself have no time for endless debates - i have things to do in
Debian and upstream. And it's just boring to read the same arguments pro
and esp. contra again and again. I was quiet until now because the
debate don't change anything for me firsthand. I use dh for all my
packages already and don't think i will change it in the future. The
very most packages i'm interested in are dh - so no problem for me to
read and maybe fix them if needed. Will i touch complex things written
in cdbs? Hell no. Will i touch other complex things not in dh - hell,
no, not worth the time. One might think of as a bit stubborn or short
sighted, but to be true: It's lack of motivation - learning a bunch of
things i'm not interested in to change things i'm not that interested
in? Sounds nuts.
A solution could be: Deprecate some thing like cdbs an others if they
are really deprecated, be verbose about why and don't let packages that
using these things go into the repository. Can be done stepwise.
My 2ยข
Alf
