public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ben Widawsky <ben@bwidawsk.net>
To: "Keith Packard" <keithp@keithp.com>
Cc: airlied@gmail.com, Akshay Joshi <me@akshayjoshi.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	dri-devel@lists.freedesktop.org
Subject: Re: Whitespace cleanups in drm/i915
Date: Fri, 16 Sep 2011 18:01:02 -0700	[thread overview]
Message-ID: <20110916180102.79997d61@bwidawsk.net> (raw)
In-Reply-To: <yun8vppw9lu.fsf@aiko.keithp.com>

On Thu, 15 Sep 2011 18:37:33 -0700
"Keith Packard" <keithp@keithp.com> wrote:

> 
> I've got this nice patch from Akshay Joshi that removes almost all of
> the checkpatch.pl warnings from drm/i915. If I don't merge it now,
> it's going to go stale and be useless; if I merge it only to
> drm-intel-next, it will be the source of endless conflicts.
> 
> However, it's a huge patch (yes, the code was rather sloppy), and
> doesn't exactly fit into the "critical patches only please" mode of
> the current stage of 3.1 development.
> 
> I've checked the patch very carefully, using the obvious git diff -b
> to make sure it really doesn't touch anything but whitespace, but also
> using objdump -s to compare the output of the compiler. There were no
> differences found with git-diff -b. The only differences found by
> objdump are two whitespace changes in some debug output messages in
> intel_bios.c.
> 
> I think I have three choices:
> 
>  1) merge the patch and expect complaints from upstream
> 
>  2) thank Akshay for his good intentions, discard the patch and hope
>     that he feels motivated enough to do it all over again in time for
>     the 3.2 merge window.
> 
>  3) thank Akshay for his good intentions and leave the code as-is,
>     forever to ease back-porting of fixes to older kernel versions.
> 
> Frankly, if we're ever going to merge whitespace fixups, this would
> be a pretty darn good time; drm-intel-fixes and drm-intel-next are
> in-sync as I haven't started pulling 3.2 code into -next.
> 

Not that you asked for a vote, but I vote either 1, or 3. In that order.
Let's either do it now, or never, and have the code slowly migrate over time
(kind of like Daniel said).

My only concern is the 80 characters per line rule. I'd hate to see some of
those nice readable lines go just because it's > 80.

Ben

  parent reply	other threads:[~2011-09-17  1:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-16  1:37 Whitespace cleanups in drm/i915 Keith Packard
2011-09-16 14:31 ` Daniel Vetter
2011-09-17  1:01 ` Ben Widawsky [this message]
     [not found] ` <CAC7LmnuOieBzq=833UOjbdPfdjQaHWou_keu0_coZ-KCFJ2kaw@mail.gmail.com>
2011-09-21 20:56   ` Akshay Joshi
2011-09-21 22:20     ` Keith Packard

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=20110916180102.79997d61@bwidawsk.net \
    --to=ben@bwidawsk.net \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=keithp@keithp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@akshayjoshi.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