Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hi Sean,
On Tue, Jun 07, 2022 at 04:35:24PM -0700, Sean Whitton wrote:
> I disagree with you that this is primarily about package ownership, and
> I think that we agree on more than you realise we do :)
Hmm. It's not that obvious. While it would be possible to remove the
choice of workflow from strong package ownership, the way we practice
package ownership presently grants that freedom. Therefore I think they
still are closely related.
> 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.
I find it interesting that you seem to equate git-first with dgit. My
mental model separated those concepts and considered git-first workflows
on salsa as well. And once you equate them, you can derive a lot of
conclusions. In my previous mail, I stated that dgit provides the sort
of uniformity I was looking for quite many aspects. I'm less sure that
all git-first users are dgit users though.
> 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.
I do see how this is a dgit goal. It just seems to me that dgit bolts a
secondary workflow onto packages that maintainers are free to ignore
entirely. Some choose to use that dgit workflow exclusively and others
don't. In a sense, the problem with dgit is that it leaves too much
freedom to maintainers (and in a project like Debian, it really has to
do exactly that or it would run into straight opposition).
> 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'.
Indeed, dgit kinda faces a chicken & egg problem and it seems that it is
quite good at solving it: The usefulness of dgit grows with its
adoption. I have looked into replacing my apt source workflow with dgit
clone a number of times already and will continue trying.
> 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.
I think I take more issue with non-dgit git-first workflows than with
dgit ones, because dgit is so well documented and is a workflow that is
already shared by a noticeable fraction of the archive.
What is not entirely clear to me is why dgit requires the 1.0-with-diff
format features. It seems to me that it quite happily deals with a
number of 3.0 (quilt) packages already. I suppose that you'll now
explain to me how some git trees are not representable as 3.0 (quilt)
packages, but do those exist in practice or are those mostly
pathological?
> > 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'
I've seen this argument multiple times already and indeed dgit solves
part of the uniformity issues. However, dgit history often lacks
maintainer history (and in that way is little better than apt source)
and it also lacks a collaboration feature that would save me from
sending a .debdiff to the bts. Possibly, such a collaboration feature is
out-of-scope for dgit, but then maybe it is not the kind of tool solving
the problem of streamlining cross-archive work.
Either way, my understanding is that unless maintainers switch to using
dgit primarily, we just gain a secondary workflow here.
> 2. develop git-first workflows that solve all the existing usecases.
Can i rephrase that as follows? Implement so many features into dgit
that its workflow covers the needs of existing workflows and hope for
maintainers to migrate to dgit.
It feels a bit like https://xkcd.com/927/ (14 competing standards ->
15). On the other hand, dgit is remarkably successful already.
I had hoped that we could kinda trim the available workflows eventually.
It seems like you want to let them all die slowly and concurrently.
> > 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.
That's a bold statement. I don't think there is "the git-first work".
Instead there is lots of concurrent git-first workflows that are all
somewhat similar and yet subtly different. Those subtle differences is
what I would like to get rid of.
Now we've turned a discussion about source package formats into a
discussion about workflows and git. So when I reason about uniformity, I
effectively want those idiosyncratic workflows to go away. If dgit
requires 1.0-with-diff for now, then maybe we could phrase it as an
exception that is specific to dgit and limited until a better solution
(such as the format proposed by Ian) is mature. If there are more
git-first workflows beyond dgit that we want to support, maybe we can
require declaring a working Vcs-Git for 1.0-with-diff uploads?
Helmut
Reply to: