Re: RFC: Github PR bot questions

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


Hi Laurent,

On Thu, Jun 17, 2021 at 5:24 PM Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:
> 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).

I thought so, too, until I received a first comment on an individual commit
in a github PR yesterday[1].

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

That's definitely not a problem that originated on git..b. Been like that
in the corporate world before.  Guess what happened after switching
from a more-forgiving VCS to git, and seeing

    Aborting commit due to empty commit message.

? ... Dummy commit messages, of course.




Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[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