Re: RFC: Github PR bot questions

[Geert Uytterhoeven <geert@linux-m68k.org>]

Hi Laurent,

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

[1] https://github.com/esmil/linux/commit/f5b077c3e80d85b1c2749999c9f74491f69a6ceb#comments

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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