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
signature.asc
Description: signature
_______________________________________________ git-buildpackage mailing list [email protected] http://lists.sigxcpu.org/mailman/listinfo/git-buildpackage
