Thread (17 messages) 17 messages, 12 authors, 2022-01-09

Re: Review process improvements

flat view

From: Christian Couder <hidden>
Date: 2021-12-20 10:48:40
Also in: workflows

On Fri, Dec 17, 2021 at 11:00 PM Konstantin Ryabitsev
[off-list ref] wrote:
On Thu, Dec 16, 2021 at 02:46:21PM -0800, Emily Shaffer wrote:
quoted
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!
quoted
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.

[...]
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help