1 |
> On 11 Mar 2022, at 19:39, Joshua Kinard <kumba@g.o> wrote: |
2 |
> |
3 |
> On 3/11/2022 03:54, Mart Raudsepp wrote:> Ühel kenal päeval, N, 10.03.2022 |
4 |
> kell 18:18, kirjutas Joshua Kinard: |
5 |
>>> I stick to the officially-published method of checking and committing |
6 |
>>> changes: |
7 |
>>> https://devmanual.gentoo.org/ebuild-maintenance/git/index.html |
8 |
>>> |
9 |
>>> The two tools highlighted there for the bulk of the work is repoman |
10 |
>>> and pkgdev. repoman is cited twelve times, pkgdev is cited six times. |
11 |
>>> pkgcheck is mentioned once. pkgcommit has no mentions. |
12 |
>>> |
13 |
>>> From that, one should not be faulted for assuming that repoman is the |
14 |
>>> more important tool, if not preferred tool, with pkgdev coming in |
15 |
>>> second place. pkgcheck comes across as entirely optional and even |
16 |
>>> seems equivalent to 'repoman full', and how would one know that |
17 |
>>> pkgcommit even exists? |
18 |
>> |
19 |
>> I believe the very purpose of this thread is to have a consensus/pre- |
20 |
>> announcement before actually editing the official documentation as part |
21 |
>> of the process of deprecating repoman. |
22 |
> |
23 |
> I feel that the documentation should have had more mentions of these newer |
24 |
> tools as their adoption by other developers accelerated. Documentation |
25 |
> doesn't have to have a fixed point in time when it fully changes over. It |
26 |
> can change organically, like almost everything else in the project. |
27 |
|
28 |
Well, I've done that. I've been adding pkgcheck and pkgdev to the devmanual |
29 |
over time, and to the wiki. |
30 |
|
31 |
> [snip] |
32 |
|
33 |
>> Also the benefit of using pkgcheck is to actually be able to make the |
34 |
>> same checks that CI would do before you push, so you can amend your |
35 |
>> commits to fix issues before they hit the server and CI and break the |
36 |
>> tree. pkgcheck is so fast that it can do full tree checks in a |
37 |
>> reasonable time (repoman would take days on a radiator mips when you go |
38 |
>> outside single package), and I believe has features to have it check all |
39 |
>> your commits that haven't been pushed yet at once, checking only what it |
40 |
>> can to not be too slow to not use (so you don't need to run the check |
41 |
>> with each commit but for all of them once you commit - and if issues, |
42 |
>> again, git interactive rebase). |
43 |
> |
44 |
> Speed is really not a big issue for me. I run repoman from my amd64 dev |
45 |
> box, and it's like, maybe 10-13 seconds at most during 'repoman full'? And |
46 |
> my MIPS systems, while not the slowest of slow of that arch, they do teach |
47 |
> you patience over the years. |
48 |
> |
49 |
> The other bits you mention about pkgcheck do sound useful, though. But I am |
50 |
> a stickler for official documentation, because my risk aversion level when |
51 |
> committing to a public repo that can affect hundreds of thousands of users |
52 |
> is *extremely* high. When I first signed up as a dev and we had the |
53 |
|
54 |
It is already mentioned in the devmanual, but we can add it in more places |
55 |
if you specify which. |