Re: [gentoo-dev] Deprecating repoman

[Joshua Kinard]

On 3/11/2022 03:54, Mart Raudsepp wrote:> Ühel kenal päeval, N, 10.03.2022
kell 18:18, kirjutas Joshua Kinard:
>> I stick to the officially-published method of checking and committing
>> changes:
>> https://devmanual.gentoo.org/ebuild-maintenance/git/index.html
>>
>> The two tools highlighted there for the bulk of the work is repoman
>> and pkgdev.  repoman is cited twelve times, pkgdev is cited six times.
>> pkgcheck is mentioned once.  pkgcommit has no mentions.
>>
>> From that, one should not be faulted for assuming that repoman is the
>> more important tool, if not preferred tool, with pkgdev coming in
>> second place. pkgcheck comes across as entirely optional and even
>> seems equivalent to 'repoman full', and how would one know that
>> pkgcommit even exists?
>
> I believe the very purpose of this thread is to have a consensus/pre-
> announcement before actually editing the official documentation as part
> of the process of deprecating repoman.

I feel that the documentation should have had more mentions of these newer
tools as their adoption by other developers accelerated.  Documentation
doesn't have to have a fixed point in time when it fully changes over.  It
can change organically, like almost everything else in the project.


>
>> That all said, most of my checks are done pre-commit, not pre-push.
>> It's annoying trying to unwind a commit with a mistake in git, so I
>> aim to not have any in the commit itself.  By the time I get to the
>> push stage, everything MUST be perfect before I hit 'git push'. Cause
>> once something is public, there's no going back.  In a handful of
>> cases, I've gone as far as nuking my local copy of the tree, re-
>> cloning it, and re-doing everything again just to fix a mistake that I
>> should have caught pre-commit.
>
> git commit --amend, interactive rebase, etc (all before push). I suggest
> to learn them and embrace them. Re-cloning is not fun, just for
> something that a quick interactive rebase or even a git reset -- hard
> destructive operation instead of re-clone would solve.

The few times I resorted to a re-clone, the damage done was beyond
recoverability of --amend or even rebase.  I don't really remember the
specifics, as the last time I did a full re-clone was maybe 14-17 months
ago.  My developer tree lives on my NAS now with ZFS snapshotting, so
recovery is a lot easier, even if I have a really old snapshot.


> Also the benefit of using pkgcheck is to actually be able to make the
> same checks that CI would do before you push, so you can amend your
> commits to fix issues before they hit the server and CI and break the
> tree. pkgcheck is so fast that it can do full tree checks in a
> reasonable time (repoman would take days on a radiator mips when you go
> outside single package), and I believe has features to have it check all
> your commits that haven't been pushed yet at once, checking only what it
> can to not be too slow to not use (so you don't need to run the check
> with each commit but for all of them once you commit - and if issues,
> again, git interactive rebase).

Speed is really not a big issue for me.  I run repoman from my amd64 dev
box, and it's like, maybe 10-13 seconds at most during 'repoman full'?  And
my MIPS systems, while not the slowest of slow of that arch, they do teach
you patience over the years.

The other bits you mention about pkgcheck do sound useful, though.  But I am
a stickler for official documentation, because my risk aversion level when
committing to a public repo that can affect hundreds of thousands of users
is *extremely* high.  When I first signed up as a dev and we had the
gentoo-x86 CVS repo, there were no CI checks.  It was the responsibility of
the dev committing to get it right the first time, or else.  The fact I
haven't blown the tree up in years, even using archaic workflows, should be
proof enough that what I do does work, even if it is sub-optimal in the eyes
of others.

If we do deprecate repoman, that's fine.  I'll learn the new tooling.  My
initial beef was the use of subjective opinion in proposing the initial
change in the first place.  Even if it is blatantly obvious to many that A >
B, these mailing lists serve as a public archive of our work, so when
proposing key changes, regardless of how many people know/don't know about
something, full justification needs to be stated clearly and openly.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@g.o
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic