Re: RFC: Github PR bot questions

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


On Wed, Jun 16, 2021 at 01:18:13PM -0400, Konstantin Ryabitsev wrote:
> - My general assumption is that putting this bot on
>   would not be useful, as this will probably result in more noise than signal.
>   I expect that subsystem maintainers would prefer to configure their own
>   GitHub projects so they can have full control on what kind of CI prechecks
>   must succeed before the series is sent out. Is that a valid assumption, or
>   should I be working towards having a single point of submission on each
>   forge platform (Github, Gitlab, etc)?

What ever repo you put this on, it's going to take constant maintenance
to keep it up to date and prune out the PRs that are going to accumulate
there, as well as deal with the obvious spam and abuse issues that
popular trees always accumulate.

Linus has already said to not do it on his "tree", and I offer a full
"all branches" kernel mirror on github as well, but I don't want to be
responsible for this type of mess.

So perhaps you get a new "mirror" account somehow and put it
there?  But again, someone will be responsible for keeping it alive and
clean, a thankless task that will take constant work.

> - We can *probably* track when patch series get applied and auto-close pull
>   requests that are accepted -- but it's not going to be perfect (we'd
>   basically be using git-patch-id to match commits to pull requests). Or is it
>   better to auto-close the pull request right after it's sent to the list with
>   a message like "thank you, please monitor your email for the rest of the
>   process"? The latter is much easier for me, of course. :)

Auto-close is the only way to do this, otherwise someone will have to go
back and clean it up on their own.  Again, who is going to do that?


greg k-h

[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