All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Eli Carter <eli.carter@inet.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Documentation/SendingPatches [2 of 2].
Date: Wed, 11 Jun 2003 17:27:31 -0400	[thread overview]
Message-ID: <200306111727.31651.rob@landley.net> (raw)
In-Reply-To: <3EE793DD.7080408@inet.com>

On Wednesday 11 June 2003 16:41, Eli Carter wrote:
> Rob Landley wrote:
> > The bit about log rolling.
> >
> > --- linux-new/Documentation/SubmittingPatches	2003-06-11
> > 15:54:29.000000000 -0400 +++
> > linux-new/Documentation/SubmittingPatches2	2003-06-11 15:54:06.000000000
> > -0400 @@ -92,6 +92,16 @@
> >  complete, that is OK.  Simply note "this patch depends on patch X"
> >  in your patch description.
> >
> > +In politics, there's a concept called "log rolling", where unrelated
> > +amendments are bundled together so that changes people want grease the
> > +way for changes they don't.  Do not do this.  It's annoying.
> > +
> > +In coding, this sort of thing can be very subtle, such as performance
> > increases +that help your new version perform as well as the original
> > while doing more +work, but which could also have been applied to the
> > original making it even +faster.  The linux-kernel guys are very good at
> > taking the chocolate coating +and leaving the pill behind.  This can be
> > very frustrating to developers, but +it's one of the big reasons open
> > source produces such excellent results.
>
> They are also likely to tell _you_ to take the pill out, clean up the
> chocolate, and resubmit; and that takes more of _your_ time.

Oh sure. :)

I pondered adding various comments along the lines of "Don't insult the 
intelligence of the people you're sending it to by assuming they can't break 
it out for themselves.  Do assume they're lazy enough to tell YOU to do it, 
and reject the whole patch until then.  Ask yourself: would you rather get 
some of your code into the kernel, or none at all?"

And also a longer admonition, that getting mad about this sort of thing is a 
very common problem among newbies, and you just have to grow up and learn to 
leave all-or-nothing behind and live with shades of grey to function around 
here in the long term.

But I was trying very hard to keep it short.  Feel free to amend the patch if 
you can think of anything better to say. :)

I was also trying not to wander off topic.  There are all sorts of related 
areas like "gradual transition" vs "flag day" approaches to large patches.  
For now, if they're doing a large enough patch we can assume they've been 
enculturated.  (Well, mostly.)  In the long term, "theory of linux-kernel 
development" might not belong belong in SubmittingPatches.  Maybe a seperate 
document, or in a FAQ somewhere, or the README...  Dunno.

> (And I do like that you broke the log rolling change out; very good
> object lesson. :) )
>
> Eli

Thanks.  It seemed the thing to do. :)

Rob

      reply	other threads:[~2003-06-11 21:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-11 20:18 [PATCH] Documentation/SendingPatches [2 of 2] Rob Landley
2003-06-11 20:41 ` Eli Carter
2003-06-11 21:27   ` Rob Landley [this message]

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=200306111727.31651.rob@landley.net \
    --to=rob@landley.net \
    --cc=eli.carter@inet.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 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.