All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt LaPlante <kernel1@cyberdogtech.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: linux-kernel@vger.kernel.org, trivial@kernel.org
Subject: Re: [PATCH] 2.6.21-git15 - Kconfig Cleanup
Date: Fri, 18 May 2007 15:09:53 -0400	[thread overview]
Message-ID: <20070518150953.c647230b.kernel1@cyberdogtech.com> (raw)
In-Reply-To: <20070518180154.GA6291@stusta.de>

On Fri, 18 May 2007 20:01:54 +0200
Adrian Bunk <bunk@stusta.de> wrote:

> On Fri, May 18, 2007 at 01:04:41PM -0400, Matt LaPlante wrote:
> 
> > ping?
> 
> Noone disagreed, and trivial patches will be forwarded again during the 
> 2.6.23 merge window.

Ok, I didn't know it would be acceptable without an ack from someone... (is Randy on vacation? :)

I know we've discussed the logic behind trivial merges going in prior
to RC candidates, and generally I think it's sound enough (we don't
want to disrupt the merging of patches that actually "matter," etc).
I don't want to create a redundant conversation here, but I'm
compelled to ask for opinions on this...  I think the Kconfigs are a
fairly prominent kernel feature, and would expect a lot of systems
people will be seeing them when the new version goes final.  That also
means that a lot more people will be seeing the "trivial" errors in
spelling or grammar that are being left in until the next version.  In
this round, for example, the new blackfin entries were really in need
of some love.

I don't really know how many people will report such things, or submit
duplicate patches for them before we actually get to the next kernel
cycle, but it seems like a waste to me.  I don't really care so much
about fixes to the Documentation texts or source comments because, in
my estimation, they probably have a much smaller audience than the
kernel configuration interface.  I guess I'm just more sensitive to
the presentation aspects of a project than the average developer, but
I can't help feel it's a shame when we're willing to show the public
such an unpolished face in a "final" product.  To me, good code is
taken down a notch by haphazard presentation.

Thoughts?

Cheers,
Matt

> 
> cu
> Adrian
> 
> -- 
> 
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed
> 


-- 
Matt LaPlante
CCNP, CCDP, A+, Linux+, CQS
kernel1@cyberdogtech.com


  reply	other threads:[~2007-05-18 19:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-12  2:05 [PATCH] 2.6.21-git15 - Kconfig Cleanup Matt LaPlante
2007-05-18 17:04 ` Matt LaPlante
2007-05-18 18:01   ` Adrian Bunk
2007-05-18 19:09     ` Matt LaPlante [this message]
2007-07-27  2:59       ` Matt LaPlante

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=20070518150953.c647230b.kernel1@cyberdogtech.com \
    --to=kernel1@cyberdogtech.com \
    --cc=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trivial@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.