Re: [gentoo-dev] Deprecating repoman

[Sam James <sam@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4893 bytes --]



> On 10 Mar 2022, at 23:18, Joshua Kinard <kumba@gentoo.org> wrote:
> 
> On 3/10/2022 14:58, Alec Warner wrote:
>> On Thu, Mar 10, 2022 at 10:27 AM Joshua Kinard <kumba@gentoo.org> wrote:
>>> 
>>> On 3/9/2022 16:00, Matt Turner wrote:
>>>> I'd like to deprecate and ultimately remove repoman. I believe that
>>>> dev-util/pkgcheck and pkgcommit (from app-portage/mgorny-dev-scripts)
>>>> are far superior replacements, and it makes sense to have people using
>>>> the same tool and seeing the same warnings as in the CI.
>>>> 
>>>> Are there any useful checks or behaviors of repoman that are missing
>>>> from pkgcheck and pkgcommit?
>>>> 
>>>> Thanks,
>>>> Matt
>>> 
>>> repoman has been //the// goto tool for checking in a change since before I
>>> was a developer in 2003.  It does everything we need, in one simple tool.
>>> Your proposal looks to replace repoman's functionality (and snark) with two
>>> or more packages, including tools from a package named after a fellow developer.
>>> 
>>> Additionally, "I believe that <foo> are far superior replacements" is an
>>> entirely subjective opinion and, frankly, completely invalid as
>>> justification to replace a tool that has worked fine for the last 20+ years.
>>> What is so fundamentally broken about repoman that cannot be fixed such
>>> that it needs total replacement by multiple independent tools?  Please
>>> document. the pros and cons here so that we can all make an informed decision.

Matt could've given more details about why pkgcheck is superior but I think
this is actually showing/exposing the problem again: we've assumed that
everybody should really know repoman lacks a significant number of the checks
pkgcheck has, as well as being much slower.

Those are the two reasons why it's superior.

>> 
>> So here is the more basic argument, you can agree or disagree.
>> 
>> *The goal I want is for people to commit to the tree and not break things.*
> 
> This goal I agree with, and I am rather pedantic about.  If not mildly
> fearful of.  We've all been there at least once in our dev-lives.  It's
> almost a rite of passage, if you will, to break the tree with a dumb commit
> at least once.  Goal is to never repeat that mistake again.
> 

Right. I spend a fair amount of time fixing issues with repoman doesn't
find but pkgcheck / CI does, or filing bugs for them.

> 
>> If we could accomplish this with no tooling at all, that would be
>> great. Sadly humans are fallible and so we have tools to check their
>> work. Currently this tooling has two parts:
>> - pre-push tooling that you run prior to pushing.
>> - post-push CI tooling that informs you when you break the tree.
>> 
>> So holding to our goal of not breaking the tree, it's better for
>> developers to run the same QA tool in pre-push that CI is using,
>> because our metric for 'breaking the tree' is the CI tool and if the
>> CI tool passes locally, there is a strong likelihood it will not break
>> in CI either. Note this argument is generic, I'm not even saying which
>> tools are in use, or which tools are better, or anything like that.
>> 
>> Here we see Matt discussing a workflow he finds frustrating.
>> - A developer does a push.
>> - Their push breaks CI.
>> - He inquires about their workflow.
>> - He learns they did not run the CI tool in their pre-push workflow.
>> - He tells them they should run the CI tool in their pre-push workflow.
>> - This happens many times, causing this thread.
>> 
>> The point of the thread then is to convince people to run the CI tool
>> in pre-push, as a matter of policy, to reduce tree breakage and reduce
>> the occurrence of the above conversation.
> 
> 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.

pkgcommit is just a wrapper around git and pkgcheck, so it is there.

It's not like you aren't allowed to make your own wrappers or aliases or scripts, right?


>> 
> 
> Back in mid-2002, it was exactly Gentoo's snarkness that tipped the scales
> for me.  I'd just given up on FreeBSD-4.x on a sparc64 machine (old Sun
> Blade 100) and LFS turned out to not be a lot of fun, but Gentoo worked fine
> on it.  All of the colors on the terminal gave it zing and pop, and made it
> rather fun to work with.  rpm and apt-get were dull;  emerge was cheeky and
> playful!  Still is to this day.
> 

I have no objection to (and in fact would rather welcome) contributions
to make other tools more "Gentoo-like". Could you make a PR or provide
some patch to add some more personality to them?

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]