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
Hey all,

With this mail I want to address the biggest issue we currently have
in proxy-maint. As you're all probably aware, addition of new
packages to ::gentoo through proxy-maint have been stalled.

It's not on purpose, and I'm sorry to every contributor so far for
negligence towards your contributions - this situation doesn't feel
nice to us either. Why are new packages processed so slowly then?

  1: Priorities. We prioritize packages that are already in ::gentoo
     to try and keep ::gentoo repo in good, up-to-date state. For
     some time now, even contributions to self-maintained packages
     have been taking a long time to process. If you have a non new
     package pull request assigned to proxy-maint without any
     attention for +30 days, please ping us. The notifications are
     probably drowned in the sea of e-mails.

     Adding new packages to the tree will increase this workload and
     response time to already slowly processed self-maintained /
     maintainer-needed packages.

  2: Hastiness. I've seen some new packages being offered a day after
     their initial release. We'd much prefer to have a dev with
     commit access to introduce it in the tree, so we like to give
     some time for anyone else to add it. I appreciate the enthusiasm
     here though.

  3: New package review procedure. Reviewing new packages take
     considerably longer time than reviewing existing packages. We
     check that licenses match, available build systems, configure
     options, requirements, docs, tests, existing upstream issues and
     possible Gentoo bugs. It is quite a heavy process and time spent
     on a new package review usually allows reviewing multiple
     contributions on existing packages. Then with new packages we
     attempt to test multiple USE flag combinations.

     Here's a good checklist for any contribution though.

  4: New contributors. Usually when meeting someone not too familiar
     with Gentoo we end up teaching them a lot of our standards, and
     basic git workflow. Like our QA policies, ebuild syntax and git
     commit requirements. (GLEPs 66 & 76)

     This paired with already heavy review package process.

  5: Trust issues. We have too many examples of a contributor
     getting their package in and vanishing. No bug fixes and no
     version bumps after. This leaves us frustrated with larger
     amount of work. Next steps include trying to get in touch with
     them for weeks / months, retiring the maintainer, putting their
     package(s) to maintainer-needed and sending e-mails to mailing
     lists. This all increases maintenance burden on us outweighing
     the value of their initial contribution.

     I do get it, life happens, distro hop happens, but in future I'd
     somehow like to be sure the contributor will stick with us for a
     longer time.

What do I suggest? For now, you've approached us with new packages.
I'd like to turn that around and for us to approach you. This'd be
done by putting any new packages into GURU overlay for now,
where we can monitor activity of a contributor and their ebuild

With introduction of GURU overlay's Github mirror each commit can be
commented on in Github, and it's easier for anyone to review
commits. It's also easier for devs to approach contributions
suggesting to finally pulling them into ::gentoo. This'd free you
from the await of comments regarding your new package pull requests.
Note that even with Github mirror up, the commits are still done to

I am not suggesting we are never going to accept new packages via
proxy-maint here; I'm saying we are hands-full keeping up with
contributions to existing packages. There is currently ~60 unreviewed
PRs assigned to proxy-maint (and multiple waiting for fixes from the
author), and more gets opened daily. Not counting new packages.

There is ~120 open pull requests for new packages, where probably
most without any kind of feedback. GURU would allow you to receive
feedback and offer the package to be used by an audience already.

All the talk above concerns just Github pull requests. I don't think
anyone is looking at Bugzilla new package bugs at all currently. For
anyone waiting on feedback on those...

I'd view this as a temporary solution for now, and hope to catch up
dealing with existing PRs in a timely manner.

-- juippis


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