All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Pawel Osciak <p.osciak@samsung.com>
Cc: "'Aguirre, Sergio'" <saaguirre@ti.com>,
	linux-media@vger.kernel.org,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	kyungmin.park@samsung.com
Subject: Re: [PATCH v2] v4l: videobuf: code cleanup.
Date: Wed, 24 Mar 2010 11:54:23 -0300	[thread overview]
Message-ID: <4BAA279F.6050505@redhat.com> (raw)
In-Reply-To: <4BA130A3.6060203@redhat.com>

Mauro Carvalho Chehab wrote:
> Pawel Osciak wrote:
>>> Aguirre, Sergio wrote:
>>>> Make videobuf pass checkpatch; minor code cleanups.
>>> I thought this kind patches were frowned upon..
>>>
>>> http://www.mjmwired.net/kernel/Documentation/development-process/4.Coding#41
>>>
>>> But maybe it's acceptable in this case... I'm not an expert on community policies :)
>> Hm, right...
>> I'm not an expert either, but it does seem reasonable. It was just a part of the
>> roadmap we agreed on in Norway, so I simply went ahead with it. Merging with other
>> patches would pollute them so I just posted it separately. I will leave the
>> decision up to Mauro then. I have some more "normal" patches lined up,
>> so please let me know. I'm guessing we are cancelling the clean-up then though.
> 
> It is fine for me to send such patch in a series of changes. A pure CodingStyle patch
> is preferred if you're doing lots of changes, since it is very easy to review those
> changes. Yet, I generally hold pure CodingStyle changes to happen at the end of an
> rc cycle, to avoid conflicts with real patches, especially when the change is on a
> code that use to have lots of changes during a kernel cycle.
> 
> In the specific case of videobuf, I prefer to merge any changes functional changes at the
> beginning of a -rc cycle, and after having several tested-by replies with different
> architectures and boards, as a trouble there will affect almost all drivers.

I'm applying this CodingStyle fix to the tree. Better applying it sooner than later.

Cheers,
Mauro

  reply	other threads:[~2010-03-24 14:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-17 13:04 Pawel Osciak
2010-03-17 13:04 ` [PATCH v2] v4l: videobuf: code cleanup Pawel Osciak
2010-03-17 14:08   ` Aguirre, Sergio
2010-03-17 14:15     ` Pawel Osciak
2010-03-17 14:29       ` Hans Verkuil
2010-03-17 14:34         ` Aguirre, Sergio
2010-03-17 14:43           ` Pawel Osciak
2010-03-17 19:42       ` Mauro Carvalho Chehab
2010-03-24 14:54         ` Mauro Carvalho Chehab [this message]
2010-03-24 15:49           ` Hans Verkuil
2010-03-17 14:26     ` Hans Verkuil
2010-03-17 14:32       ` Aguirre, Sergio
2010-03-17 20:34   ` Hans Verkuil
2010-03-17 21:03     ` Mauro Carvalho Chehab

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=4BAA279F.6050505@redhat.com \
    --to=mchehab@redhat.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=p.osciak@samsung.com \
    --cc=saaguirre@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.