| 1 |
Hey all, |
| 2 |
|
| 3 |
With this mail I want to address the biggest issue we currently have |
| 4 |
in proxy-maint. As you're all probably aware, addition of new |
| 5 |
packages to ::gentoo through proxy-maint have been stalled. |
| 6 |
|
| 7 |
It's not on purpose, and I'm sorry to every contributor so far for |
| 8 |
negligence towards your contributions - this situation doesn't feel |
| 9 |
nice to us either. Why are new packages processed so slowly then? |
| 10 |
|
| 11 |
1: Priorities. We prioritize packages that are already in ::gentoo |
| 12 |
to try and keep ::gentoo repo in good, up-to-date state. For |
| 13 |
some time now, even contributions to self-maintained packages |
| 14 |
have been taking a long time to process. If you have a non new |
| 15 |
package pull request assigned to proxy-maint without any |
| 16 |
attention for +30 days, please ping us. The notifications are |
| 17 |
probably drowned in the sea of e-mails. |
| 18 |
|
| 19 |
Adding new packages to the tree will increase this workload and |
| 20 |
response time to already slowly processed self-maintained / |
| 21 |
maintainer-needed packages. |
| 22 |
|
| 23 |
2: Hastiness. I've seen some new packages being offered a day after |
| 24 |
their initial release. We'd much prefer to have a dev with |
| 25 |
commit access to introduce it in the tree, so we like to give |
| 26 |
some time for anyone else to add it. I appreciate the enthusiasm |
| 27 |
here though. |
| 28 |
|
| 29 |
3: New package review procedure. Reviewing new packages take |
| 30 |
considerably longer time than reviewing existing packages. We |
| 31 |
check that licenses match, available build systems, configure |
| 32 |
options, requirements, docs, tests, existing upstream issues and |
| 33 |
possible Gentoo bugs. It is quite a heavy process and time spent |
| 34 |
on a new package review usually allows reviewing multiple |
| 35 |
contributions on existing packages. Then with new packages we |
| 36 |
attempt to test multiple USE flag combinations. |
| 37 |
|
| 38 |
Here's a good checklist for any contribution though. |
| 39 |
|
| 40 |
4: New contributors. Usually when meeting someone not too familiar |
| 41 |
with Gentoo we end up teaching them a lot of our standards, and |
| 42 |
basic git workflow. Like our QA policies, ebuild syntax and git |
| 43 |
commit requirements. (GLEPs 66 & 76) |
| 44 |
|
| 45 |
This paired with already heavy review package process. |
| 46 |
|
| 47 |
5: Trust issues. We have too many examples of a contributor |
| 48 |
getting their package in and vanishing. No bug fixes and no |
| 49 |
version bumps after. This leaves us frustrated with larger |
| 50 |
amount of work. Next steps include trying to get in touch with |
| 51 |
them for weeks / months, retiring the maintainer, putting their |
| 52 |
package(s) to maintainer-needed and sending e-mails to mailing |
| 53 |
lists. This all increases maintenance burden on us outweighing |
| 54 |
the value of their initial contribution. |
| 55 |
|
| 56 |
I do get it, life happens, distro hop happens, but in future I'd |
| 57 |
somehow like to be sure the contributor will stick with us for a |
| 58 |
longer time. |
| 59 |
|
| 60 |
What do I suggest? For now, you've approached us with new packages. |
| 61 |
I'd like to turn that around and for us to approach you. This'd be |
| 62 |
done by putting any new packages into GURU overlay for now, |
| 63 |
https://wiki.gentoo.org/wiki/Project:GURU/ |
| 64 |
where we can monitor activity of a contributor and their ebuild |
| 65 |
quality. |
| 66 |
|
| 67 |
With introduction of GURU overlay's Github mirror each commit can be |
| 68 |
commented on in Github, and it's easier for anyone to review |
| 69 |
commits. It's also easier for devs to approach contributions |
| 70 |
suggesting to finally pulling them into ::gentoo. This'd free you |
| 71 |
from the await of comments regarding your new package pull requests. |
| 72 |
Note that even with Github mirror up, the commits are still done to |
| 73 |
gitweb.gentoo.org. |
| 74 |
https://github.com/gentoo/guru |
| 75 |
|
| 76 |
I am not suggesting we are never going to accept new packages via |
| 77 |
proxy-maint here; I'm saying we are hands-full keeping up with |
| 78 |
contributions to existing packages. There is currently ~60 unreviewed |
| 79 |
PRs assigned to proxy-maint (and multiple waiting for fixes from the |
| 80 |
author), and more gets opened daily. Not counting new packages. |
| 81 |
|
| 82 |
There is ~120 open pull requests for new packages, where probably |
| 83 |
most without any kind of feedback. GURU would allow you to receive |
| 84 |
feedback and offer the package to be used by an audience already. |
| 85 |
|
| 86 |
All the talk above concerns just Github pull requests. I don't think |
| 87 |
anyone is looking at Bugzilla new package bugs at all currently. For |
| 88 |
anyone waiting on feedback on those... |
| 89 |
|
| 90 |
I'd view this as a temporary solution for now, and hope to catch up |
| 91 |
dealing with existing PRs in a timely manner. |
| 92 |
|
| 93 |
-- juippis |
Archives