Re: RFC: Github PR bot questions

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


On Thu, Jun 17, 2021 at 04:16:59PM +0100, Mark Brown wrote:
> On Thu, Jun 17, 2021 at 10:57:28AM -0400, Konstantin Ryabitsev wrote:
> > On Thu, Jun 17, 2021 at 11:09:34AM +0100, Christoph Hellwig wrote:
> > > Because I don't waste my time on the kind of crap that comes from
> > > github.  If you build a separate webinterface that allows anyone to send
> > > a proper series from a git tree that is all fine.  But github is toxic.
> > Won't this just end up reimplementing a lot of stuff that we already get "for
> > free" from Github and other forges? Yes, I know Github is proprietary, but so
> > are many SMTP gateways used to send the patch series. I don't see how what
> > the GH bot would do is different from:
> I think part of the concern here is that people have some standard
> expectations for how projects they work with on Github are going to
> function so if people end up using Github to submit patches we may end
> up with some culture and process mismatches which could cause issues.

There are some features (or lack thereof) of git..b that I suspect
actively decrease the quality of the hosted software. For instance, the
inability to comment on the commit messages during review can play a
role in the average low quality of those messages. Similarly, review is
often based on changes, not on individual commits, which results in
commits being badly split (or not split at all, it's common to see very
large commits with a "fix stuff" commit message).

Developers who have only been exposed to those platforms are very likely
to never have learnt the importance of commit messages, and of proper
split of changes across commits. Those are issues that are inherent to
those platforms and that we will likely need to handle in an automated
way (at least to some extent) or maintainers will become crazy (I know
we already suffer from those issues with the mailing list-based
workflow, but I believe it would get worse, not better, and some of our
maintainers are already suffering way more than they should).


Laurent Pinchart

[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