Re: On pull request workflows for the GNU toolchain

[enh via Gdb <gdb@sourceware.org>]

it doesn't make the patch _management_ problem better ("now i have two
problems"), but https://github.com/landley/toybox takes the "why not both?"
approach --- you can use pull requests if you grew up with/adapted to
git/github, or you can use the mailing list otherwise ... taking into
account that what the "barriers" are depend on whose eye's you're looking
through.

somewhat related, Android's NDK uses github as their issue tracker [while
still having Google's usual "buganizer" issue tracker available] and we get
orders of magnitude more interaction with our users on github --- like it
or not, it's where the users are. anecdotally i notice people report
bugs/send patches to github _mirrors_ of AOSP projects, and have no idea
that's not the actual upstream.


On Mon, Sep 23, 2024 at 9:23 AM Jonathan Wakely <jwakely.gcc@gmail.com>
wrote:

> On Mon, 23 Sept 2024 at 13:09, Thomas Koenig via Gcc <gcc@gcc.gnu.org>
> wrote:
> >
> > [For the fortran people: Discussion on gcc@]
> >
> > Just a general remark.
> >
> > There are people, such as myself, who regularly mess up
> > their git repositories because they have no mental model
> > of what git is doing
>
> I highly recommend https://www.youtube.com/watch?v=1ffBJ4sVUb4 which
> gives an excellent mental model for the basics (and everything else
> follows from those basic rules).
>
> > (case in point: The Fortran unsigned
> > branch, which I managed to put into an unrepairable state
> > despite considerable help from people who tried to help me
> > fix it). This is especially true of volunteer maintainers,
> > who are still the mainstay of gfortran.
> >
> > Whatever you end up doing, consider such maintainers, and
> > if they still can contribute or would simply give up.
> > If what you end up doing is too complicated, it may end up
> > severely impacting the gfortran project (and possibly others).
>
> We already use Git in all the toolchain projects and there's no
> suggestion to change that.
>
> The discussion is about how we do patch submission and patch review.
> The GitHub pull request workflow is widely seen as simpler than our
> current email-based workflow (not everybody agrees, of course). The
> idea is to *lower* the barrier of entry for contributors, not raise
> it.
>