Linux Media Controller development
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: SF Markus Elfring <elfring@users.sourceforge.net>
Cc: Hans Verkuil <hverkuil@xs4all.nl>, linux-media@vger.kernel.org
Subject: Re: [GIT PULL FOR v4.15] Cleanup fixes
Date: Sat, 23 Sep 2017 16:25:50 -0300	[thread overview]
Message-ID: <20170923162550.503c9cf2@vento.lan> (raw)
In-Reply-To: <b33aac55-6749-3dc9-1258-c6518b05a94e@users.sourceforge.net>

Em Sat, 23 Sep 2017 16:43:53 +0200
SF Markus Elfring <elfring@users.sourceforge.net> escreveu:

> >> coccinelle, checkpatch, coverity, etc.  
> …
> > It **really** doesn't makes any sense to send patch bombs like that!  
> 
> I got an other impression for this software development aspect.
> 
> 
> > That pisses me off, as it requires a considerable amount of time from
> > my side that could be used handling important stuff...  
> 
> I can partly understand this view.
> 
> 
> > You're even doing the same logical change on the same driver several times,
> > like this one:
> > 	atmel-isc: Delete an error message for a failed memory allocation in isc_formats_init()
> > 	atmel-isi: Delete an error message for a failed memory allocation in two functions  
> 
> Such a change approach can occasionally occur because of my selection
> for a specific patch granularity.

Then change patch granularity: one patch per subsystem or per
directory (e. g. pci, usb, platform, others).

> 
> > Instead, group patches that do the same thing per subsystem.  
> 
> I was also uncertain about the acceptance for the suggested
> change patterns.

That's the usual criteria most maintainers use for cleanups.

> Do you want a “development pause” from my queue of change possibilities?

Those patches are mainly source code "polishing". I really don't
want to take much time handling such kind of patches, as they
usually doesn't fix any real bug, nor add functionality.

So, if you really want to contribute, the best is to buy yourself
some media devices, test them and send patches fixing real bugs
and improving the functionality of them.

Regards,
Mauro

  reply	other threads:[~2017-09-23 19:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-08 14:34 [GIT PULL FOR v4.15] Cleanup fixes Hans Verkuil
2017-09-23 12:38 ` Mauro Carvalho Chehab
2017-09-23 14:43   ` SF Markus Elfring
2017-09-23 19:25     ` Mauro Carvalho Chehab [this message]
2017-09-23 20:02       ` SF Markus Elfring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170923162550.503c9cf2@vento.lan \
    --to=mchehab@s-opensource.com \
    --cc=elfring@users.sourceforge.net \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox