Re: Review process improvements

From: Christian Couder <christian.couder@gmail.com>
Date: Dec 20, 2021, 10:48 UTC
Message-ID: <CAP8UFD1M7LM630iHXb3EhgiRSoHgKzixTHmKYTA5OU1fEo69DA@mail.gmail.com>
In-Reply-To: <20211217183942.npvkb3ajnx6p5cbp@meerkat.local>

On Fri, Dec 17, 2021 at 11:00 PM Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

Show 7 quoted lines

>
> On Thu, Dec 16, 2021 at 02:46:21PM -0800, Emily Shaffer wrote:
> > Some of those discussions resulted in changes - for example,
> > GitGitGadget was improved and added to git/git, and we enjoy easy,
> > non-noisy CI runs via GitHub Actions. But some things we thought were a
> > good idea never went into practice. In the next few months, the Google
> > Git team is planning to implement some of the following changes,

Thanks for trying to make it easier and more efficient to contribute!

Show 6 quoted lines

> > and
> > we'd appreciate your thoughts ahead of time as well as your review later
> > on:
>
> I'd like to also mention that I'm hoping to add a few more features to b4 that
> will hopefully improve the patch submission process for folks.

Thanks also for implementing and maintaining tools and sites that help contributing!

I have added a new "Process related tools and sites" section to https://git.github.io/Hacking-Git/ with links to GitGitGadget, lore.kernel.org/git, public-inbox, lore+lei, b4 and git-series. I am willing to add other tools and sites if someone knows others worth mentioning.

[...]

Show 8 quoted lines

> > 1. Draft a MAINTAINERS file
>
> So, I *don't* recommend that you go this route. The biggest problem with the
> MAINTAINERS file as used by the Linux development community is that making
> changes to it is a very high-latency process. It will be less of a problem for
> the much smaller git developer community, but it will still result in folks
> operating from a stale copy of the file for weeks after it is updated
> upstream.

My opinion is that a MAINTAINERS file makes more sense when there are different mailing lists to send patches to, and trusted lieutenants/maintainers. I am not sure that we are at that point yet.

About documentation, if some good documentation exists elsewhere, it might be good enough to just point to it from an existing doc and/or https://git.github.io/Hacking-Git/. Otherwise adding a new separate doc might be better than growing an existing doc too much, which could scare new comers.