On Fri, 11 Aug 2023 19:10:36 +0300 Joonas Niilola <juip...@gentoo.org> wrote:
> On 11.8.2023 17.07, orbea wrote: > > Hi, > > > > Currently the Gentoo Github PR queue is at 577 open PRs that even > > includes one that has been left open in 2018 and neglected since > > 2021. > > That's a bit misleading. The PR in question is opened by a Gentoo > developer, and labeled as "do-not-merge". So maybe they lost interest, > or forgot? Ping in the PR if you want to see it finished. But there > are indeed tons of PRs open from 2020. Good point, I should of looked closer and found a more appropriate example. > > > > > > While not trying to be rude before contributing to Gentoo I was > > involved with Slackbuilds.org for Slackware where everything gets > > reviewed once a week with only a handful of maintainers doing the > > reviewing process. > > We also have 32,000 PRs closed, while slackbuild is at 3000. And here > also only handful of members are putting effort in general PR review. > So I'd say we're doing pretty good in that regard. Using github and gitlab are recent additions for SBo, their main repo is maintained with cgit. https://git.slackbuilds.org/slackbuilds/ More regular and trusted contributors push to their own branches which get merged roughly once a week while other people use the submission form. https://slackbuilds.org/guidelines/ Where the pending and approved submissions are listed here. https://slackbuilds.org/pending/ https://slackbuilds.org/ready/ Again these get merged about once a week where the SBo maintainers fix any minor issues themselves and contact the submitter usually via irc or e-mail for anything more involved. > > > > > > Why does Gentoo lets PRs indefinitely sit around and collect dust? > > Its extremely discouraging for contributors if their work just gets > > ignored. With some extra work I imagine its possible to get the PR > > queue to a much more manageable size where work doesn't get lost. > > > > It is discouraging I agree. Even for us. If you want to help, go > through the old PRs seeing which are relevant, ping the maintainers > if the PR is waiting for action on their side, and let us know (via > IRC for example) which PRs are mergeable. > > Now as to the problems. We've done some cleanups in the past, but in > my opinion it's no point in putting too much energy on that if > there's are many fresh PRs to look at. We shouldn't lose the > momentum. There's also this handy tool, > https://github.com/wimmuskee/gengee > which I used a lot in the past but haven't been able to recently due > to always looking at few week old PRs. > > Another big issue is as mjo pointed out, not everyone uses GH. But > don't be fooled, I don't think you're gaining better record attaching > your work to bugzilla either. It really depends on the maintainer > whether they prefer contributions via GH or BZ, and we've tossed some > ideas in the past trying to show maintainer's preference, but nothing > came of those ideas. Then unfortunately some maintainers who'll > ignore both exists. > > There's pretty much only 1 project dealing with Github PRs > (proxy-maint) and that project only gets notified with packages under > maintainer-needed, or maintained via proxy-maint itself. This project > doesn't get notified for _every_ PR opened, which I believe is a > common misconception. And it shouldn't either. There's simply too > much incoming mail even with few projects. So it's up to projects > handling their own PRs, but again, not everyone uses GH / care about > PRs. > > What I suggest for everyone to do: > 1: open a bug that gets assigned to maintainer, > 2: link your PR to the bug with "Bug:" or "Closes:" tag, > 3: if no one reviews it for 2-4 weeks, pop into #gentoo-proxy-maint > IRC channel and ask someone to take a look. > > Open bug is a requirement for other non-project members to merge your > work, since it allows maintainer timeout. Note that packages > maintained by base-system and toolchain can't be merged by devs > outside these projects. > > -- juippis Perhaps the correct answer would be neither Bugzilla or Github? Bugzilla may be a good way to track bugs, but attaching work to it can be cumbersome. Meanwhile Github has the benefit of using git which can be more convenient, but also is proprietary and owned by Microsoft. However thank you for the in depth explanation.
