Message-ID: <2025071510-skeleton-squealer-f9bc@gregkh>
Date: Tue, 15 Jul 2025 09:04:42 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Martin Weidenauer <martin@...denauer.cc>,
	Woohee Yang <woohee9527@...il.com>, Jongmin Kim <jmkim@...ian.org>,
	hansg@...nel.org, mchehab@...nel.org, sakari.ailus@...ux.intel.com,
	andy@...nel.org, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-staging@...ts.linux.dev,
	~lkcamp/patches@...ts.sr.ht, koike@...lia.com
Subject: Re: [PATCH] staging: atomisp: isp: fix open brace on new line

On Tue, Jul 15, 2025 at 09:57:19AM +0300, Andy Shevchenko wrote:
> On Tue, Jul 15, 2025 at 12:54 AM Martin Weidenauer <martin@...denauer.cc> wrote:
> > On 14 July 2025 23:38:47 CEST, Andy Shevchenko <andy.shevchenko@...il.com> wrote:
> > >On Mon, Jul 14, 2025 at 10:39 PM Martin Weidenauer <martin@...denauer.cc> wrote:
> > >> On 14 July 2025 19:47:41 CEST, Andy Shevchenko <andy.shevchenko@...il.com> wrote:
> > >
> > >> >Guys, please, coordinate and issue only one (or a few) patch(es) per
> > >> >an issue. No need to send zillions patches for the same problem
> > >> >file-by-file.
> > >
> > >> >On Mon, Jul 14, 2025 at 6:34 PM Martin Weidenauer <martin@...denauer.cc> wrote:
> > >> >>
> > >> >> Fix checkpatch error "ERROR: that open brace { should be on the previous line"
> > >> >> in ia_css_dvs.host.c:277.
> > >
> > >> I deeply apologize, however this was the instruction of our workshop in DebConf by Helen Koike <koike@...lia.com>
> > >
> > >This may be okay for the driver that consists of let's say less than
> > >10 files, AtomISP consists of dozens of files in several (nested)
> > >folders. It's not a good example for such an approach.
> > >
> > >> Here is the link to the exact workshop:
> > >> <https://debconf25.debconf.org/talks/55-submit-your-first-contribution-to-the-linux-kernel/>
> > >
> > >Hmm... this really needs an update to explain how to work with the
> > >drivers that contain many files and literally tens of thousands lines
> > >of code.
> > >
> > >In any case the problem with your contribution is not the code, the
> > >absence of coordination and possibility to clash with somebody else.
> > >Also it looks like a DDoS attack against maintainers capacity. The
> > >smaller patches are and the more of them --- the less the usefulness
> > >of all this activity as at some point that floods the maintainer's
> > >mailbox.
> > >
> > >TL:DR; (always) Use common sense!
> >
> > To be honest, such a contribution also seemed to me a bit useless but I thought all of this had been discussed with you maintainers beforehand.
> >
> > As it seems this was not the case, although the workshop has shown us how easy it is to make contributions and for my part I will use the knowledge to make meaningful changes.
> > So you can scrap this commit and I'll make a few commits in the next days which make more sense.
> 
> The problem is not the code, the contribution is okay and appreciated.
> The problem is that for _the same_ issue there are tons of patches
> from _different_ people. Just discuss who does what and send "one
> contributer == one issue" (under one issue, I mean class of the issues
> checkpatch or other tools report, for instance, the "if (foo)
> return;"-like which are on one line and needs to be two or more lines,
> do _all_ of them by _a single_ contributor.

No, that's not necessary at all, really.  Just take them in the order
they come in and review/apply them as normal.  Don't expect people to
coordinate together, especially for staging stuff, that's crazy.

This is just part of staging, it's the maintainers job to help guide new
contributors like this.  If you don't want to do this, that's fine, just
delete these media drivers out of staging then.  And don't blame the
submitters, it's not their fault at all.

thanks,

greg k-h

Powered by blists - more mailing lists