Re: [gentoo-dev] Deprecating repoman

[Joshua Kinard]

On 3/11/2022 20:54, Sam James wrote:
>
>
>> On 11 Mar 2022, at 19:39, Joshua Kinard <kumba@g.o> wrote:
>>
>> 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.
>
> Well, I've done that. I've been adding pkgcheck and pkgdev to the devmanual
> over time, and to the wiki.

Yes, I'd seen that, though at least in the ebuild maintenance section on
git, pkgdev's mentions were added in such a way that it was implied to be
comparable to repoman.  Not better than repoman, as many people here are
stating.

People like me, when we see that, are going to conduct an internal risk
assessment.  Use what I know works and get results I know I will get, or use
a completely new tool that I know nothing about, and maybe get the same
result with no perceived benefit or gain.


>> [snip]
>
>>> 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
>
> It is already mentioned in the devmanual, but we can add it in more places
> if you specify which.

Matt's posted a pull request in GH that looks to eliminate all remaining
references of repoman and replace them with pkgdev.  So I think we're done
with this point now once that request is merged in.

-- 
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