• [gentoo-dev] Massive Github PR Queue

    From orbea@21:1/5 to All on Fri Aug 11 16:10:01 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From orbea@21:1/5 to Michael Orlitzky on Fri Aug 11 16:50:01 2023
    On Fri, 11 Aug 2023 10:19:29 -0400
    Michael Orlitzky <mjo@gentoo.org> wrote:

    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Orlitzky@21:1/5 to orbea on Fri Aug 11 17:10:01 2023
    On Fri, 2023-08-11 at 07:46 -0700, orbea wrote:

    Understandable, but I still don't get how 1 or 2 people can take care
    of SBo every week while Gentoo the process stagnates.

    Probably due to compartmentalization. In Gentoo you're often waiting
    for one maintainer. Or worse, waiting for one "project" consisting of
    several people none of whom actually care about the package the PR
    touches.



    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


    Linking a bug was a half-hearted attempt to appease the folks who think
    that Gentoo development shouldn't depend on proprietary software (per
    our social contract). But if the bug just points me to Github, it
    doesn't really change anything.

    I of course have a comprehensive list of Github complaints in mind 24
    hours a day, but they're not especially relevant. What is relevant is
    that some other developers have their own list, and sometimes you're
    waiting on one developer who doesn't like to use Github for whatever
    reason. My personal PR queue is of length zero, so I'm not making
    excuses, but when you want something done for free it's in your best
    interest to make it easy for the person who has to do it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Orlitzky@21:1/5 to orbea on Fri Aug 11 16:20:02 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joonas Niilola@21:1/5 to orbea on Fri Aug 11 18:20:01 2023
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------nP3UMsq8N6NdryX5GWnQBQzT
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    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

    --------------nP3UMsq8N6NdryX5GWnQBQzT--

    -----BEGIN PGP SIGNATURE-----

    iQGTBAEBCgB9FiEEltRJ9L6XRmDQCngHc4OUK43AaWIFAmTWXX1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2 RDQ0OUY0QkU5NzQ2NjBEMDBBNzgwNzczODM5NDJCOERDMDY5NjIACgkQc4OUK43A aWLt0wgApY8kl/+c0Y1iDIXb8dM1u2BvgHiQdmmRDhRsis9QrytRXV5Oy4t6GCCi +Hmx+sZ2BHLtt/cYMZ1H6P9COwlGdX3bMwhVeujy3+pVb9nHtROorsI7il63sGGt S43gZyDELZAKl1itfeuZO43wm0O5gkS4/CChX0urQYqQ01puEASRJTrLu8808aCu ZJUlAR7kfcLfVgLmKdOda01QnU2jQ7HX7plsPtY+PYP1TpuOV1UqeLHuIsM9QGKp Jfc5+2na287Oa5D6y4ZzuVCtQyUpxqVGo6slixaxsRGdKHmHCmROo4g7ukshYcF+ b+bLTTtWDR8nBLJBmfrCoYeg1bBksA==
    =W1YV
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam James@21:1/5 to Joonas Niilola on Fri Aug 11 19:00:01 2023
    Joonas Niilola <juippis@gentoo.org> writes:

    [[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.


    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.

    as for bz: it's far harder to review something on bz and if everyone
    did that for their contributions, any backlog (which you can't
    easily measure on bz either) would be far larger.

    [...]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From orbea@21:1/5 to Joonas Niilola on Fri Aug 11 19:40:01 2023
    On Fri, 11 Aug 2023 19:10:36 +0300
    Joonas Niilola <juippis@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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich Freeman@21:1/5 to sam@gentoo.org on Fri Aug 11 20:20:01 2023
    On Fri, Aug 11, 2023 at 12:54 PM Sam James <sam@gentoo.org> wrote:
    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.

    ++

    In general the Gentoo workflow tends to be a bit different from a lot
    of other projects as well, with quite a bit more individual
    ownership/interest. Many distros just stick to core packages in a
    main repo, and consign everything else to user-maintained
    repos/overlays/etc, or tiers with lower expectations for quality.

    Then you have all the build-related issues that can be hard to
    reproduce/test, that other distros simply don't have to worry about
    because they only support one or two build configurations.

    Another thing I've seen in fairly large projects is auto-closing of issues/bugs/PRs/etc. If your submission sits around for more than a
    few weeks without getting merged, a bot comes along and helpfully
    marks it closed. That of course results in a nice low open-issue
    count, but of course that doesn't mean those issues are actually
    fixed.

    --
    Rich

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gordon Pettey@21:1/5 to juippis@gentoo.org on Sat Aug 12 01:40:01 2023
    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.

    <div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 11, 2023 at 11:11 AM Joonas Niilola &lt;<a href="mailto:juippis@gentoo.org">juippis@gentoo.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:
    0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> Another big issue is as mjo pointed out, not everyone uses GH.<br></blockquote><div><br></div><div>&quot;Not using GitHub&quot; 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&#39;s no &quot;using github&quot; required for that beyond clicking the link in the attached bug to see the PR and the remote repository name. For the 202 &quot;bug linked&quot; (
    excluding &quot;new package&quot;) PRs, ~50% are more than 6 months old. While that doesn&#39;t necessarily mean they&#39;ve been ignored (for the &quot;not using GitHub&quot; devs, the code could&#39;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&#39;t look great.<br></div></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Orlitzky@21:1/5 to Gordon Pettey on Sat Aug 12 03:40:01 2023
    On Fri, 2023-08-11 at 18:37 -0500, Gordon Pettey wrote:

    "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.

    We went years with one developer refusing to fix tinderbox bugs because
    the build logs were hosted on AWS instead of bugzilla.

    These are Gentoo Linux developers. People who chose a corner case
    operating system and then chose a corner case distribution of it and
    then became a corner case of its userbase. As a result, you're going to
    see some corner-case moral and technical principles. Telling someone
    that those principles aren't an excuse just isn't going to get them to
    help you any faster.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Orlitzky@21:1/5 to orbea on Sat Aug 12 03:20:02 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=@21:1/5 to Michael Orlitzky on Sat Aug 12 04:40:01 2023
    On Fri, 2023-08-11 at 21:18 -0400, Michael Orlitzky wrote:
    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'm sure that having to go through 15 threads where people reposted
    the same patches with updates to find all the comments will be a great productivity booster.

    --
    Best regards,
    Michał Górny

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Gilbert@21:1/5 to mjo@gentoo.org on Sat Aug 12 04:20:02 2023
    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:

    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
    through the trouble of fetching patches from my email than fetching a
    branch from GitHub.

    <div>On Fri, Aug 11, 2023 at 21:18 Michael Orlitzky &lt;<a href="mailto:mjo@gentoo.org">mjo@gentoo.org</a>&gt; wrote:<br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-
    style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On Fri, 2023-08-11 at 10:35 -0700, orbea wrote:<br>
    &gt; <br>
    &gt; Perhaps the correct answer would be neither Bugzilla or Github?<br>

    A mailing list (whose archives work :o) with git-send-email threads<br>
    would be an improvement over both.<br>


    </blockquote></div></div><div dir="auto">I don’t think replacing pull requests with mailing list posts would yield any significant improvement. Personally, I am much less likely to go through the trouble of fetching patches from my email than fetching
    a branch from GitHub. </div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Haelwenn (lanodan) Monnier@21:1/5 to All on Sat Aug 12 15:40:01 2023
    [2023-08-11 22:12:27-0400] Mike Gilbert:
    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:

    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
    through the trouble of fetching patches from my email than fetching a
    branch from GitHub.

    Maybe there could be something that automatically pushes the mailing-list patches to GitHub? (and vice-versa?)

    There was such a setup for a bit on Alpine Linux[1] using https://lists.sr.ht/ as software, Drew DeVault being the one that put it together.

    1: https://lists.alpinelinux.org/~alpine/aports

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From orbea@21:1/5 to Gordon Pettey on Sat Aug 12 16:10:01 2023
    On Fri, 11 Aug 2023 18:37:10 -0500
    Gordon Pettey <petteyg359@gmail.com> wrote:

    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.

    You can just add a "Closes:" tag with the github PR url to the commit
    message for it to be closed automatically. Using app-portage/pram can
    also streamline the process of merging the commit. And if there are any
    issues that need to be communicated there is e-mail or even irc in some
    cases.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)