Gentoo Archives: gentoo-proxy-maint

From: Joonas Niilola <juippis@g.o>
To: gentoo-proxy-maint@l.g.o
Subject: [gentoo-proxy-maint] Adding new packages via proxy-maint project
Date: Wed, 18 Mar 2020 19:53:29
1 Hey all,
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.
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?
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.
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.
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.
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.
38      Here's a good checklist for any contribution though.
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)
45      This paired with already heavy review package process.
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.
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.
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,
64 where we can monitor activity of a contributor and their ebuild
65 quality.
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
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.
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.
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...
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.
93 -- juippis


File name MIME type
signature.asc application/pgp-signature