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
