Re: Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello,
On Tue 07 Jun 2022 at 08:19pm +02, Helmut Grohne wrote:
> Please keep in mind that this is about trade-offs. It is a question of
> how we value "package ownership". If we favour the strong ownership
> approach that Debian used for a long time, then yes accommodating the
> needs of maintainers is paramount. If we want to lessen the concept of
> ownership, embrace drive-by contributions and decentralize maintenance,
> then we need a stronger focus on uniformity. I suppose that my own
> opinion on this matter is fairly obvious at this point.
I disagree with you that this is primarily about package ownership, and
I think that we agree on more than you realise we do :)
The git-first people are not making a trade-off between the maintainer's
convenience and the convenience of others who want to work with the
package. The most important reason for wanting both (i) git-first
workflows and (ii) uploads done with dgit, is to make it easier for
people other than the maintainer to work with the package. So, your
priorities are quite in agreement with those of Ian, Sam, Russ and I.
In other words, I would like to make weaker package ownership more
possible, in a project with Debian's history, by improving our tools for
dealing with packages for which you're not primary maintainer.
What we disagree about is the extent to which the current tooling
amounts to a failed experiment, such that we should give up on it and
fall back to 'apt-get source'. Many people strongly prefer 'dgit clone'
to 'apt-get source' already, and the number of people switching to
upload with 'dgit [--gbp] push-source' is steadily rising. Against this
backdrop, some of us are interested in git-first workflows for reducing
the distance between the output of 'debcheckout' and 'dgit clone'.
It's completely reasonable that you're more sceptical about the
prospects of solving the outstanding issues in this programme than
others are, but surely we can agree that this is an ongoing piece of
work rather than something we're sure we can reject? And if keeping an
old source package format around is needed for that work to continue,
then that's a compelling reason to keep it around.
> How would you go about reducing them to a sane number?
The goal is to attack this problem on two fronts:
1. reduce the need for uniformity by making it possible for people to
get their cross-archive work done using 'dgit clone'
2. develop git-first workflows that solve all the existing usecases.
> You can rephrase it as reducing complexity if that helps. It's not the
> one additional source package format that is too much. It's that we
> continue using all the failed experiments while adding new ones and when
> some Lucas comes around and tries to clean up the mess he gets referred
> to us.
As I said, I don't think it's fair to characterise the git-first work as
a failed experiment. It's ongoing work. And the source package format
is just a way to keep it going, at the present moment.
> I have anecdotal evidence that people find Debian's processes too
> complex. Unless you closely work withing a particular packaging team
> (with unified processes), onboarding people into Debian takes very long
> compared to other projects.
Right, hence why we want 'dgit clone' to be as useful as possible.
--
Sean Whitton
Reply to: