| 1 |
On Wed, 8 Jul 2020 02:57:57 +0000 |
| 2 |
Max Magorsch <arzano@g.o> wrote: |
| 3 |
|
| 4 |
> Additionally, there are new sites for all package maintainers, that is: |
| 5 |
> - Gentoo Projects (e.g. python@g.o) |
| 6 |
> - Gentoo Developers (e.g. larry@g.o |
| 7 |
> - Proxied Maintainers (e.g. larry@×××××××.de) |
| 8 |
|
| 9 |
Some other thoughts here, I've found it very helpful when working on |
| 10 |
our *very* large set of responsibilities, to be able to cluster |
| 11 |
problems alphabetically. |
| 12 |
|
| 13 |
For instance, |
| 14 |
|
| 15 |
> https://packagestest.gentoo.org/maintainer/perl@g.o/outdated |
| 16 |
|
| 17 |
Is a bit of an unwieldy mountain to conquer, and it may be better to |
| 18 |
paginate it by the first letter of ${PN}, or cluster it. |
| 19 |
|
| 20 |
So you could have: |
| 21 |
|
| 22 |
Outdated: |
| 23 |
dev-perl/A*: 4 packages |
| 24 |
dev-perl/B*: 6 packages |
| 25 |
dev-perl/C*: 1234 packages |
| 26 |
|
| 27 |
And expand each into their composites on demand. |
| 28 |
|
| 29 |
Though it also helps to point out I generally approach this as: |
| 30 |
|
| 31 |
- Target dev-perl/A*: |
| 32 |
- for each dev-perl/A*, enumerate everything, absolutely everything, |
| 33 |
about each and every package that may warrant my attention, be it |
| 34 |
- being outdated |
| 35 |
- having open bugs |
| 36 |
- having keywording/stabilization bugs |
| 37 |
- having minor/major QA issues. ( for instance, one right now is |
| 38 |
"no versions are >EAPI5" ) |
| 39 |
|
| 40 |
And I use this as my baseline, and then walk through them all |
| 41 |
alphabetically, applying whatever local testing regimen required to |
| 42 |
find various classes of bugs that are getting reported lately, applying |
| 43 |
relevant local audits to find bugs that *could* be filed in future. |
| 44 |
|
| 45 |
And its generally easier to tackle the problem when segmented this way. |
Archives