public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Jens Frederich <jfrederich@gmail.com>
Cc: devel@driverdev.osuosl.org, Greg KH <gregkh@linuxfoundation.org>,
	Jon Nettleton <jon.nettleton@gmail.com>,
	Daniel Drake <dsd@laptop.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] Staging: olpc_dcon: replace some magic numbers
Date: Fri, 16 Aug 2013 11:54:19 +0300	[thread overview]
Message-ID: <20130816085419.GD26086@mwanda> (raw)
In-Reply-To: <CAF92urq-bL_y9zjt9THh-LJjxrMYmdjwr7RssgBk+zxC-OhRdQ@mail.gmail.com>

On Fri, Aug 16, 2013 at 09:40:38AM +0200, Jens Frederich wrote:
> On Fri, Aug 16, 2013 at 9:13 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > On Thu, Aug 15, 2013 at 09:34:55PM +0200, Jens Frederich wrote:
> >> The 0x42 initialize squence 0x101 is wrong.  According to
> >> the specification Bit 8 is reserved, thus not in use.
> >> I removed it.
> >
> > Really these code changes should be in a separate patch and labeled
> > "Don't set reserved bit." instead of hidden away inside a cleanup
> > patch.
> >
> 
> The patch is applied. Still, good to know. It's not so easy to find the
> right patch granularity as newbie.
> 

Yeah.  Staging is for educating people about kernel process as much
as it is about writing code.

The rule here is "Don't mix code changes into a cleanup patches."
What we want is if you have a bug then you can look through
`git log --oneline` output and guess which patch introduced the bug.
This patch is a cleanup patch so it shouldn't introduce any code
changes or any bugs.

Meanwhile, if you are making a code change you can make any cleanups
you need to in order to do the change.  Also if there is an existing
checkpatch warning on any of the lines you touch, then that's ok to
fix as well.  Or if there are tiny related changes than that's fine.

There are three problems with big patches:
1) It breaks the --oneline summary to mix two things into one patch.
2) It makes the patch harder to review.  For example, sometimes
   people fix a bug and rename 10 variables as well.
3) The more lines your patch is, the more chance there is that we
   will reject it based on one of those lines.  You don't like
   redoing patches and we don't like making people redo them.  So
   small patches are better and put the more controversial ones at
   the end so the first patches can be applied.

No one totally agrees what "small closely related cleanups" means so
it's better to be conservative.

regards,
dan carpenter


  reply	other threads:[~2013-08-16  8:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-15 19:34 [PATCH 2/3] Staging: olpc_dcon: replace some magic numbers Jens Frederich
2013-08-16  7:13 ` Dan Carpenter
2013-08-16  7:40   ` Jens Frederich
2013-08-16  8:54     ` Dan Carpenter [this message]
2013-08-16 11:04       ` Jens Frederich

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=20130816085419.GD26086@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=dsd@laptop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jfrederich@gmail.com \
    --cc=jon.nettleton@gmail.com \
    --cc=linux-kernel@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