On Fri, 2023-08-11 at 07:07 -0700, orbea wrote:
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.
Reviewing a PR takes longer than doing it yourself would, and if you
had time to do it yourself there wouldn't be a PR in the first place.
But also, Github sucks. Open bugs.
Understandable, but I still don't get how 1 or 2 people can take care
of SBo every week while Gentoo the process stagnates.
But also, Github sucks. Open bugs.
No disagreements and personally I wouldn't use Github if not for it
being beyond my control, but there are still 235 open PRs with bugs
assigned.
https://github.com/gentoo/gentoo/pulls?q=is%3Apr+is%3Aopen+label%3A%22bug+linked%22
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.
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.
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.
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.
[[PGP Signed Part:Undecided]]
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.
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.
[...]
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.
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.
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
juippis' whole email nails the issue, but I'd just like to add that
there's kind of a baseline at ~400/~450 or so where everything below
that is PRs for new packages or long-obsolete stuff nobody closed yet,
or where we're waiting on the submitter. It's just that going ahead
and going over those is time-consuming and means we're spending less
time on active PRs which need looking at.
Another big issue is as mjo pointed out, not everyone uses GH.
"Not using GitHub" is not an excuse for a PR to sit ignored when it has a
bug attachment. Anyone can view a PR anonymously and clone the remote from the read-only https URL. There's no "using github" required for that beyond clicking the link in the attached bug to see the PR and the remote
repository name.
Perhaps the correct answer would be neither Bugzilla or Github?
On Fri, 2023-08-11 at 10:35 -0700, orbea wrote:
Perhaps the correct answer would be neither Bugzilla or Github?
A mailing list (whose archives work :o) with git-send-email threads
would be an improvement over both.
On Fri, 2023-08-11 at 10:35 -0700, orbea wrote:
Perhaps the correct answer would be neither Bugzilla or Github?
A mailing list (whose archives work :o) with git-send-email threads
would be an improvement over both.
I don’t think replacing pull requests with mailing list posts would yieldany significant improvement. Personally, I am much less likely to go
On Fri, Aug 11, 2023 at 21:18 Michael Orlitzky <mjo@gentoo.org> wrote:
On Fri, 2023-08-11 at 10:35 -0700, orbea wrote:through the trouble of fetching patches from my email than fetching a
Perhaps the correct answer would be neither Bugzilla or Github?
A mailing list (whose archives work :o) with git-send-email threads
would be an improvement over both.
I don’t think replacing pull requests with mailing list posts would yield >any significant improvement. Personally, I am much less likely to go
branch from GitHub.
On Fri, Aug 11, 2023 at 11:11 AM Joonas Niilola <juippis@gentoo.org>
wrote:
Another big issue is as mjo pointed out, not everyone uses GH.
"Not using GitHub" is not an excuse for a PR to sit ignored when it
has a bug attachment. Anyone can view a PR anonymously and clone the
remote from the read-only https URL. There's no "using github"
required for that beyond clicking the link in the attached bug to see
the PR and the remote repository name. For the 202 "bug linked"
(excluding "new package") PRs, ~50% are more than 6 months old. While
that doesn't necessarily mean they've been ignored (for the "not
using GitHub" devs, the code could've been merged that way without
any interaction on the GH PR, then it would be up to the submitter to
close the PR), it still doesn't look great.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 491 |
Nodes: | 16 (2 / 14) |
Uptime: | 126:17:16 |
Calls: | 9,687 |
Calls today: | 3 |
Files: | 13,728 |
Messages: | 6,177,133 |