Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello,
On Wed 08 Jun 2022 at 09:07pm +02, Helmut Grohne wrote:
> 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.
>
> 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.
Didn't mean to equate them, sorry. We can state the following:
dgit should have support for all git-first workflows. I am not sure
whether there are any git-first workflows in use on salsa for which you
can't 'dgit push-source' atm. If there are, those are dgit bugs.
> 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?
Sorry, didn't mean to suggest that dgit requires 1.0-with-diff. It does not.
>> 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)
Right, (1) is about making it easy for people to be using 'dgit
push-source' such that the maintainer history is there when you 'dgit clone'.
> 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.
Not out of scope, we have some notes for 'dgit nmudiff' in the BTS.
Would be cool to collaborate with you on finishing that up.
> Either way, my understanding is that unless maintainers switch to
> using dgit primarily, we just gain a secondary workflow here.
No -- (1) is all about ensuring that maintainers don't have to change
their workflows aside from how they do the actual upload.
>> 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 don't think it can be rephrased that way.
Firstly, (1) is about dgit, but (2) is about tools like git-debrebase(1)
and workflows such as dgit-maint-merge(7).
More substantially, (1) is about attaching maintainer histories to the
dgit view, and (2) is about developing workflows which enables the
maintainer and dgit views to be identical. That's what I mean when I
say that (1) and (2) are attacking the problem on two fronts.
(2) is particularly important for submitting NMU changes to the
maintainer -- it enables using salsa merge requests, for example.
> 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.
>
> [...]
>
> 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?
My own appraisal of the situation is that we do not know enough yet to
be thinking about cutting back on features and workflows. But I
certainly agree that it would be better to have a better solution, like
Ian's sketch.
I think Ian has already suggested adding text to our resolution
recommending the development of such a source format. To be honest I
don't think it's really necessary as everyone agrees it would be better
to have it, but if you think it should be said explicitly then let's do
that.
--
Sean Whitton
Reply to: