Re: Review process improvements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 17, 2021 at 11:00 PM Konstantin Ryabitsev
<konstantin@xxxxxxxxxxxxxxxxxxx> wrote:
>
> 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!

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

[...]

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



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux