| 1 |
I'm sorry for the belatedness in my response, I've been away for much |
| 2 |
of the voting period. |
| 3 |
|
| 4 |
I agree with some of the other's sentiment that these aren't entirely |
| 5 |
useful questions for council given council only acts on what is |
| 6 |
brought to it, but further replies below. |
| 7 |
|
| 8 |
On Thu, Jun 16, 2022 at 06:06:40PM +0000, Robin H. Johnson wrote: |
| 9 |
> A question I'd like the candidates to answer. |
| 10 |
> |
| 11 |
> What do you feel that Council can do to increase the contributions to |
| 12 |
> Gentoo? |
| 13 |
> |
| 14 |
> - how do you feel development velocity of Gentoo should be measured? |
| 15 |
> - how do you feel technical debt of Gentoo should be measured? |
| 16 |
|
| 17 |
I think Repology provides some useful metrics related to these |
| 18 |
questions: |
| 19 |
|
| 20 |
https://repology.org/repository/gentoo |
| 21 |
|
| 22 |
Somewhat less quantitatively, technical debt should also take into |
| 23 |
account this like bugs with PATCHes that haven't been handled by the |
| 24 |
maintainer(s), pull requests that remain ignored/unreviewed by |
| 25 |
maintainer(s), and how well sets of bugs on Bugzilla (i.e. bugs |
| 26 |
assigned to a maintainer or bugs for a specific package) are |
| 27 |
maintained. It's always a bit frustrating to find a package with |
| 28 |
several years of bugs that haven't been touched by the assignee. |
| 29 |
|
| 30 |
> - how do we make it easier to get orders of magnitude more contributors? |
| 31 |
> - how do we make it easier to do QA on significantly more contributions? |
| 32 |
> - what blockers do you perceive in the contribution processes, and how |
| 33 |
> do you think they should be tackled? |
| 34 |
|
| 35 |
I'll echo tooling as one of the big barriers in contribution. In the |
| 36 |
last year or two we've made leaps forward here, maybe most notably |
| 37 |
with pkgdev and iwdevtools. Slyfox also mentioned some tooling he'd |
| 38 |
like to see in his retirement blog post: |
| 39 |
|
| 40 |
https://trofi.github.io/posts/226-farewell-gentoo-dev.html |
| 41 |
|
| 42 |
A better CI process for user contributions would allow us to process |
| 43 |
user contributions much faster. This is one of the primary goals I see |
| 44 |
in transitioning to Gitlab. The current process of users opening a PR |
| 45 |
and needing someone to manually build-test it and report back any |
| 46 |
issues is tedious and slow, and we'd do better with some automated CI |
| 47 |
here. |
| 48 |
|
| 49 |
> |
| 50 |
> Many of the developers I nominated in my previous email to the -project |
| 51 |
> list were because are the very prolific contributors or have significant |
| 52 |
> impact in their contributors: how can we increase not just the prolific |
| 53 |
> contributors, but get many more contributors everywhere? |
| 54 |
|
| 55 |
We have many, many contributors who are already proxied-maintainers |
| 56 |
and we could probably do a better job of encouraging these maintainers |
| 57 |
to become developers. If we had a build CI process that automatedly |
| 58 |
reported issues with contributions, the human dependency for this |
| 59 |
would be largely eliminated and contributors wouldn't have to wait for |
| 60 |
a human to test their changes and report issues. I think this would |
| 61 |
greatly decrease the time the average PR spends open, most of which is |
| 62 |
waiting for human action. With a faster turnover for PRs, more PRs can |
| 63 |
be made more quickly. |
| 64 |
|
| 65 |
> |
| 66 |
> -- |
| 67 |
> Robin Hugh Johnson |
| 68 |
> Gentoo Linux: Dev, Infra Lead, Foundation Treasurer |
| 69 |
> E-Mail : robbat2@g.o |
| 70 |
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 |
| 71 |
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 |
Archives