Re: finally end single-person maintainership
On Tue Apr 9, 2024 at 1:52 PM -03, Wookey wrote:
> 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.
Use gbp-buildpackage --git-ignore-new. By default checks for uncommited,
so you don't ship to Debian things that are not commited. If you use
this flag, the burden of checking this lands on you.
Yet, you can still use the regular workflow to build stuff, just
dpkg-buildpackage -us -uc.
> 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...
Use git commit -p, I tend to throw -v as well, so when I am writing the
commit description I also get the diff of that commit. With -p you
basically select by blocks what goes into your commit with simple y and
n. You can also split blocks.
If you prefer to just make a bunch of small commits and then combine
them all into one big-fat commit, just use git rebase -i HEAD~N with N
being how many commits you want to rebase.
This will give you a file text where you decide which commits are
squashed onto the top one, you can also re-arrange. After you save that
file, it'll allow you to modify the commit.
So you can do a bunch of git commit -m 'random' and with git rebase -i
create a proper commit message from a bunch of commits.
> 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).
Git is the default tooling in the whole open-source ecosystem. Maybe a
poll would be good to know how much people actually is against using Git
as default, after so many years with proper git tooling in Debian. I
would not be surprised if the loud bunch in the mailing lists end-up
being very very small.
I understand is hard to have your workflows changed, but IMO it's been
too many years that Git is the default VCS everywhere. There's no other
workflow you need to change, if you use Git.
> 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)..
This is untrue. All the git tooling depends on non-git tooling for the
build. I actually have a setup for building everything on docker and
does not use any git tooling, because that's just sugar-coating for the
non-git tools.
> 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.
You can use uscan.
> 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).
I see, you are confusing two things here. Having the source from Git vs
using tarballs. And using Salsa does not requires you to have the source
from a Git and not a tarball.
> 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.
You don't need more than to learn how to use git commit and git rebase,
TBH. Having packages in Git doesn't means you have to use gbp-*.
> 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.
This is part of my workflow for actual builds:
https://github.com/resnullius/deb-build-pkg/blob/master/deb-build-pkg
https://github.com/resnullius/docker-deb-devel/blob/master/base/scripts/entrypoint.sh
And it handles packages on Git. The first is just an interface for
docker and the Docker entrypoint. The entrypoint is where the actual
packaging happens and as you can see, they are the regular:
dpkg-buildpackage, uscan, mk-build-deps.
> 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?
Salsa as default only means you have to make commits, not use any
different tooling. Just git commit and git push, nothing else.
Maybe there's a misunderstanding here where workflows need to change,
but that's not true.
There are workflows possible thanks to branches on Git, yes, but that
does not mean you have to use them in order to use Git.
Kind regards,
Jose
Reply to: