On 2024-04-08 21:44 +0900, Simon Richter wrote: > Testing a package requires me to > commit everything into git first, so I have to remember to squash all these > commits later. Right - this was (one of the) main thing(s) that annoyed me enough to just go back to the non-git based workflow. I want to make changes and try them. I don't want to have to commit every damn time - it's not done yet - I'll commit it after I'm satisfied that it works. But I don't know that until I've made a whole set of changes and it builds. So now I've got a pile of changes which should really be separate commits and logically separate things often affect the same files, and even the same lines, so really I need to commit some chunks and not others and tidy it all up. Yes this makes a nice set of commits but it's _so_ much work in comparison to just editing the damn files, and then effectively doing one fat 'commit' when I dupload. Often something ends up stalled for weeks or months or years because I've got some chunks in the wrong places and sorting it out is painful, so I go do something else and lose all my state. You all know how that goes... Sometimes git is useful - I do use it quite intensively for things where it actually helps (complicated cave survey datasets with hundreds of entangled commits that need re-ordering). For the vast majority of my debian packaging it's just makework. I realise this (like my previous message) will result in a load of people telling me git _is_ better and I'm just doing it wrong, or should learn better tools. And they may even be right, (and I will probably learn some things from this thread), but I don't believe the goal we agree on (fixing other people's packages should be culturally accepted) _requires_ this change in tooling (which is a heavy cost for at least some of us). The point here is that 'requiring salsa' is actually code for 'no, you can't just use the tarball-based VCS any more - you have to use git'. Removing that interface is a very big deal - it has served quite well for 30 years. Yes it old-fashioned and crufty and (presumably) only a minority still use it as the primary interface, but any GR on this should acknowledge what we are requiring of people still using it, not just frame this as 'and add salsa'. It's more fundamental than that (or I am misunderstanding).. Also what do you git people do to replace uscan? Currently I go to my existing version, or a newly-acquired apt get or dget source. I do 'uscan' and if there is a new upstream version I have a nice separate directly that is easy to dirdiff (then fixup any packaging and dupload). If there isn't I can move on. git world seems to make this way more complicated. I have to set up two different repos - one for salsa one for upstream, then pull them, maybe into different branches, and fight the diff config to let me dirdiff two different commits. And the upstream pull will always pull changes, not just only do it is there is an actual release (tag). None of that feels like an improvement over 'uscan'. One word for the standard process of updating to a new version. And if the patches still apply it's probably all done (I always do a meld review too to see what changed). And I do just prefer having two directories rather than multiple version on top of each other. My simple brain finds it a lot easier to keep track of a version directory to diff between, rather than finding the right runes to get git to give meld faked-up directories pointing at revisions or branches. If someone can make a tool so that this workflow still works, but a copy gets dumped into salsa, then I don't mind this new requirement. But otherwise it seems like a big imposition. I do understand the argument that lots of different workflows adds friction. But I'm just still using what used to be _the_ standard one (insofar as we ever had such a thing). Putting everything in salsa/git doesn't standardise workflows in itself. I think Ian/Sean identified 12 different git-based methods in their dgit review. Josch's suggestion that just recording the workflow in metadata would be useful is a good one. Then at least you know what other maintainers are doing. And dgit's approach of unifying the archive representation and the git representation is definitely progress in the right direction. I was very sad to find that it didn't help us 'tarball people' directly at all (except I guess to reduce exactly this pressure to stop doing it and use git). So why mandate salsa rather than make dgit more official? That lets the people that want to use git use it for everything - even the packages that were just uploaded as tarballs. And explicitly _doesn't_ remove the archive VCS interface. And it supports all the git-based workflows. (someone should probably tell IWJ this conversation is occuring as he's taken a bit intererest in it, but no longer reads debian-devel). Does than not solve a good chunk of this 'make it easy to fix other packages using your standard tools' desire? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature