[git-buildpackage] git-buildpackage defaults and most popular configurations

[Johannes Schauer Marin Rodrigues]

Quoting Otto Kekäläinen (2024-12-18 02:53:11)
> Perhaps these results could be used to advocate that pristine-tar and
> sign-tags should be enabled by default, and patch-numbers disabled, in a
> future git-buildpackage version?

Lets take pristine-tar as an example for my argument. The initial motivation of
many maintainers to put this line into their debian/gbp.conf was likely that
they wanted to choose a different value than the default. Now suppose that you
change the default. Will this mean that fewer debian/gbp.conf files will have
an entry for pristine-tar? No, because the existing entries are still relevant
to overwrite the setting that people might've put into their ~/.gbp.conf. If
multiple people work on the same package, then the settings in debian/gbp.conf
make sure that everybody is on the same page independent of their own personal
defaults in their ~/.gbp.conf. In fact, if you change the default, now even
*more* debian/gbp.conf files will have to gain an entry for pristine-tar
because now all the packages which do *not* want to use pristine-tar have a
motivation to override the new default in their debian/gbp.conf on a
per-package basis.

This is not an argument against changing the default of pristine-tar. This is
an argument that using the number of occurrences in debian/gbp.conf is a bad
metric to decide on the default. While it might've been the main motivation for
maintainers to put settings into their debian/gbp.conf that the gbp default was
different from the one they want, this should not be the reason for putting
settings in debian/gbp.conf. The actual reason should be: put everything in
there which significantly influences the packaging workflow when collaborating
with others.

So I think that if you want to make an argument for changing the default of
pristine-tar, then the argument should be made *after* we somehow more or less
decided on what the "best packaging practice" for newcomers is. Those will most
benefit from "good" default. But once they start collaborating with others,
they will have to start populating debian/gbp.conf even if the value they put
in their is the same as the default. How often a value currently exists in
debian/gbp.conf is more a metric of how disruptive it is to have a value there
that is different from the default. Or a rough rough heuristic of what the
currently most popular cargo-culted set of settings in large teams is.

In summary, I think a much better argument to touch defaults would argue with
best packaging practices, not with debian/gbp.conf.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.sigxcpu.org/pipermail/git-buildpackage/attachments/20241218/71d93252/attachment.sig>