Re: finally end single-person maintainership
Hi Wookey,
Am Tue, Apr 09, 2024 at 05:52:43PM +0100 schrieb Wookey:
> Right - this was (one of the) main thing(s) that annoyed me enough to
> just go back to the non-git based workflow.
I started packaging with VCS in 2007i. Thanks to some Debian Med team
members (mainly Charles Plessy) I was convinced to us SVN first and
later I was moved to Git (yes, I *was* moved ;-) ). I'm extremely happy
that I followed my team mates and could not imagine to move back.
> 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.
Seems like a matter of style. My team mates are accepting commits that
are not perfect and fixed later in another commit. The great thing is
that I get some proof whether my commits are working after pushing to
Salsa thanks to Salsa CI.
> 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.
I do not think everybody expects you to follow the gold standard if Git
commits. If it makes you more productive nobody will blame you about
some fat commits.
> 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.
It might be that your debian packaging is different to what I'm doing
but I do not share this experience.
> 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).
'Require' is probably the wrong word. I simply have heard from several
potential young contributors that they feel blocked by the tooling and
specifically not everything in Git. We simply have no idea what amount
of new contributors we might scare away due to sticking to habits that
feel old fashioned to those people.
> 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)..
I'm using a workflow based on git-buildpackage with pristine-tar. This
is a great wrapper for the tarball-based workflow.
> Also what do you git people do to replace uscan?
Nothing. I'm using uscan. When I realised that I'm doing always the
same for new upstream versions I wrote some semi-automated tool
routine-update which calls uscan, cme, janitor tools and is possibly the
reason why I was able to maintain the majority of packages of R pkg team
alone. Sometimes I have 4-6 xterms open with running routine-update at
the same time. Doing things semi-automated is dangerous to some extend
- thus I consider Salsa CI a great second pair of eye-balls. Without
this toolset I could not manage all this.
> 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.
I usually keep copies of most of my packaging git repositories on my
local disk. So my workflow is checking some list of packages that need
an upgrade (we update such lists in some teams twice a day). Than I move
to the local repository, run
routine-update
(works without interaction in about >80%, depending from the team)
dput
> git world seems to make this way more complicated. I have to set up
> two different repos - one for salsa one for upstream,
No. There are tag based workflows (as far as I know in openstack team)
which I personally do not understand. I'm exclusively using tarball
based workflow. When creating a new package starting with importing an
upstream tarball as first commit in a fresh repository (as I've shown in
several live packaging workshops for instance at DebConf23). I create a
local repository and a script that moves this to Salsa.
> then pull them,
> maybe into different branches,
git-buildpackage maintains two or three branches: The main packaging
branch and an upstream branch. The pristine-tar branch is optional (but
default in the teams I'm working in) and just keeps the needed
metainformation to create a byte identical tarball as downloaded by
upstream. Maintaining these are no-brainers and done automatically by
git-buildpackage (wrapped by routine-update).
> 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).
I need to admit I do not understand what you mean since I never had
to deal with those things.
> 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).
As I said routine-update is using `uscan` and checks whether patches
apply cleanly. If not it stops and tells me I need to adjust patches.
It also detects if there is just fuzz in patches, tells me to unfuzz
this in some separate terminal and continues once I confirm this is
done.
> 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.
That's probably a matter of taste. For me its definitely not
outweighting the advantages I mentioned above.
> 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 can simply unpack your old and the new upstream tarball and do
dirdiff as you want. Or am I missing something?
> 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.
I agree that different workflows are not helpful. We have DEP14[1]
... but we have no efficient processes to
a) accept DEPs
b) dedicate to accepted 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).
I need to admit I'm not actively using dgit thus can't comment on this.
But I consider myself a member of the group of 'tarball people'. I'm
old enough to stick to conservative habits. The good thing of mentoring
lots of newbies is that I learned a lot from them myself how to make
my workflow way more efficient.
> 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?
As I said I'm lacking the expertise to compare my Salsa -
gbp-buildpackage - workflow to some workflow with dgit. Refusing some
common hosting platform simply does not work for Debian wide changes
(Janitor and potential other tools which might help in transitions), no
Salsa CI and other things that are simply not possible for packages
outside Salsa.
As last remark I'd like to say again thank you to my team mates who
convinced me in 2007 (according to team metrics) to start with some VCS
based workflow which finally enabled me to become as productive as I am
now (despite I was arguing probably for 2-3 years the very same way as
you did above. ;-) ).
Kind regards
Andreas.
[1] https://dep-team.pages.debian.net/deps/dep14/
--
https://fam-tille.de
Reply to: