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
Bug#1007717: Draft resolution for "Native source package format with non-native version"
On 08/06/22 at 21:07 +0200, Helmut Grohne wrote: > 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. I'm curious: how do you measure dgit usage? You cannot just look at the list of repositories at https://browse.dgit.debian.org/, since that just says that at some point in the past, someone used dgit to work on that package, right? For example, the keepass2 package has a repo there, but it is completely outdated compared to what is in unstable. Lucas
Bug#1007717: Draft resolution for "Native source package format with non-native version"
On 08/06/22 at 21:07 +0200, Helmut Grohne wrote: > 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? I think that the workflow used by the Debian X team is such a git-first workflow that is not using dgit. That workflow combines Debian-specific patches managed by quilt, and commits cherry-picked from upstream directly applied to the source in git (outside of quilt). See There are 89 packages maintained by Debian X among the 607 packages in testing still using 1.0. Lucas
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
Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello, On Wed 08 Jun 2022 at 12:06pm +02, Julian Andres Klode wrote: > On Tue, Jun 07, 2022 at 08:19:29PM +0200, 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. > > This is also a significant issue for downstreams. With my Ubuntu hat > on, if I have to touch packages downstream, I loathe it everytime I > get a non-descript blob of all the changes. This is not inherent to all of the workflows we are discussing here, just one of them. Indeed, this is one of the primary motivations for one of the others. -- Sean Whitton
Bug#1007717: Draft resolution for "Native source package format with non-native version"
On Tue, Jun 07, 2022 at 08:19:29PM +0200, 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. This is also a significant issue for downstreams. With my Ubuntu hat on, if I have to touch packages downstream, I loathe it everytime I get a non-descript blob of all the changes. I suspect this is the same for other downstream distributions that want to modify packages. We cannot cater to everyone's individual packaging repository approach, and downstream repositories if they exist are separate anyhow. Using 1.0 instead of 3.0 (quilt) is just being a hostile upstream, like Red Hat is with dumping all their kernel patches together. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
