public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Davidlohr Bueso <davidlohr@hp.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org,
	Valentina Manea <valentina.manea.m@gmail.com>,
	Wahib Faizi <wahibfaizi@gmail.com>
Subject: Re: [PATCH v3 0/2] Fix subject line
Date: Fri, 13 Jun 2014 00:30:45 +0300	[thread overview]
Message-ID: <20140612213045.GW5500@mwanda> (raw)
In-Reply-To: <1402606118.2627.14.camel@buesod1.americas.hpqcorp.net>

On Thu, Jun 12, 2014 at 01:48:38PM -0700, Davidlohr Bueso wrote:
> On Thu, 2014-06-12 at 13:35 -0700, Greg Kroah-Hartman wrote:
> > On Thu, Jun 12, 2014 at 01:25:34PM -0700, Davidlohr Bueso wrote:
> > > On Thu, 2014-06-12 at 23:40 +0400, Wahib Faizi wrote:
> > > > Fix coding style issues detected by checkpatch.pl in usbip_host_driver.c.
> > > 
> > > Sorry but unless bundled with something more meaningful, I really don't
> > > see the value in these changes. I certainly don't want to discourage
> > > folks or anything, but just testing other patches is a lot more helpful
> > > than this. 
> > 
> > When the staging code is still needing basic fixes like this, it is
> > "meaningful" to do patches that clean up stuff like this.  That's what
> > the staging tree is for.
> 
> Sure, but "making checkpatch happy just to make checkpatch happy" isn't
> a good justification, even for staging.

It actually is.  Fighting against checkpatch is a losers battle.  Our
way more efficient.

1) We do need to fix this checkpatch warning before it moves out of
   staging.
2) NAKing patches is actually a lot of stress for everyone.  It stresses
   out submitters and drives them away.  It stresses out the
   maintainers because we feel bad.  That stress is bad when it is
   pointless.
3) This patch is ok.
4) If we don't apply this patch then someone else will send the exact
   same patch or something worse until we apply something.
5) The v3 of this patch takes under 30 seconds to review and apply.
6) Newbies feel happy when their patch gets merged and that is good.

The other thing is that if you start asking "Is this patch meaningful"
then it makes applying any patch into a big question about meaning and
it tires you out.

In staging we have clear rules for when a patch is going to be applied
and everyone understands the rules.  It means that if Greg is traveling
then you know which patches he is going to apply in what order and life
is easier because it is more predictable.

regards,
dan carpenter


  reply	other threads:[~2014-06-12 21:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Eudyptula Challenge (Task 10)>
2014-06-12 10:35 ` Eudyptula Challenge (Task 10) Wahib Faizi
2014-06-12 10:35   ` [PATCH] drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c: fix coding style Wahib Faizi
2014-06-12 14:10     ` Greg Kroah-Hartman
2014-06-12 17:32   ` Split patch into 2 logical chunks Wahib Faizi
2014-06-12 17:32     ` [PATCH v2 1/2] drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c: fix coding style Wahib Faizi
2014-06-12 17:54       ` Greg Kroah-Hartman
2014-06-12 17:55         ` Joe Perches
2014-06-12 17:32     ` [PATCH v2 2/2] " Wahib Faizi
2014-06-12 19:09   ` Fix subject line Wahib Faizi
2014-06-12 19:09     ` [PATCH 1/2] staging: usbip: usbip_host_driver.c: avoid assignment in if Wahib Faizi
2014-06-12 19:09     ` [PATCH 2/2] staging: usbip: usbip_host_driver.c: fix line over 80 characters Wahib Faizi
2014-06-12 19:40   ` [PATCH v3 0/2] Fix subject line Wahib Faizi
2014-06-12 19:40     ` [PATCH v3 1/2] staging: usbip: usbip_host_driver.c: avoid assignment in if Wahib Faizi
2014-06-12 19:40     ` [PATCH v3 2/2] staging: usbip: usbip_host_driver.c: fix line over 80 characters Wahib Faizi
2014-06-12 20:25     ` [PATCH v3 0/2] Fix subject line Davidlohr Bueso
2014-06-12 20:35       ` Greg Kroah-Hartman
2014-06-12 20:48         ` Davidlohr Bueso
2014-06-12 21:30           ` Dan Carpenter [this message]
2014-06-15 20:28       ` Wahib
2014-06-18  0:30         ` Davidlohr Bueso

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=20140612213045.GW5500@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=davidlohr@hp.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=valentina.manea.m@gmail.com \
    --cc=wahibfaizi@gmail.com \
    /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