> I'm curious about the benefit of putting gbp.conf in each package
> instead of using ~/.gbp.conf. It's painful to have to update this file
> once the team decided to change the default configuration afterward, and
> I didn't see any extraordinary setting that we need.
Large scale update are not so complicated with the appropriate tools.
Change of gbp.conf doesn't require an upload so it's ok.
We want external contributors to have the proper settings and we want
contributors who can be part of multiple teams with different settings...
The most important setting is the "debian-branch" and the "pristine-tar"
one. The others are minor.
Yeah, my idea is that having this as a team policy will reduce the work of the
maintainer, as we can automate the creation and update of this file.
As Raphaël said, the fundamental ones are debian-branch and pristine-tar,
because with them anybody who gbp clones the packages would be able to
work on it, even if this person didn't setup their gbp.conf.
The minor ones are good to have, as there are no downsides and they seem
to fit the workflows people follow in the team.
It's important to note that we will be skipping the ci when pushing such things[0]
and that he maintenance of the file would not be left to maintainers, we can do
it the same way it was with salsa-ci, and I volunteer myself to do it.
> Apart from that, I'm not sure the status of dep14 [1] (it shows
> "draft"), I think it's beneficial for development across the packaging teams.
>
> [1] https://dep-team.pages.debian.net/deps/dep14/
I should probably drop the draft status by now.
+1, I think the "Source", "Recent Changes" and "History" fields also needs to be
updated.
> > I agree it's painful to have to update this file when you work in other
> > branches, hence why I use "ignore-branch" and tend to not hardcode the
> > branch in the configuration file..
>
> How about using .git/gbp.conf (per repository)?
It doesn't help with the fact that you have to use different values for
"debian-branch" when you are in debian/master or in debian/buster or in
debian/experimental...
+1, and it also hides the file from the salsa wgui, which is not that much of a big
deal, but in an similar pro/cons scenario I would rather have it in debian/gbp.conf.