From: Steven Cole <elenstev@mesatop.com>
To: Horst von Brand <vonbrand@inf.utfsm.cl>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] 2.5.63 Nasssty little hobbitsses making ssso many sspelling misstakesses!
Date: 27 Feb 2003 08:17:12 -0700 [thread overview]
Message-ID: <1046359032.6616.271.camel@spc9.esa.lanl.gov> (raw)
In-Reply-To: <200302271328.h1RDSYd0009716@eeyore.valparaiso.cl>
On Thu, 2003-02-27 at 06:28, Horst von Brand wrote:
> Steven Cole <elenstev@mesatop.com> said:
> > This patch fixes:
> >
> > [Many typoes all over the place]
>
> I have't followed this much, but there are some lessons from the comments
> on this (and previous patches):
>
> - "isn't" (and such) get better changed to "is not", as 's give grief (at
> least in .S files)
That problem is understood and is why my patch which changed "its" to
"it's" used "it is" in the two files where that was an issue. One was
a .c file with in-line assembly.
> - I wouldn't bother too much on broken editors that don't understand 's in
> comments or strings
> - It would be better for you to tackle _all_ typoes in one area, get them
Better for some.
> fixed by the maintainer, then move on. Patches that change lines under
> the maintainers/other patches aren't wellcome, as they break the patches
> (and if they don't fix the code, people _will_ bitch at whoever
> integrates them)
I can certainly back off on these fixes or do it the way you suggest if
it's causing people any grief. Your request is the second in this area
and being an impediment to progress is the opposite of my intention.
>
> Yes, I know this is a lot of work. But as it stands, it is a lot of
> _wasted_ work if the patches aren't being integrated.
>
> Thanks!
If "the patches" in the above are my patches, then that's my problem.
If "the patches" in the above are yours and others patches, then the
problem is more generic. These typo fixes have a fairly low intrinsic
value, but the issue you raise is important.
I've seen several instances where real fixes have gotten integrated,
only to be inadvertently backed out by a subsequent unrelated patch to
the same file from another maintainer who had not recently resynced his
tree with Linus. A generic solution to that problem would have
considerable value. If we all used Bitkeeper, maybe we wouldn't have
these prob...(just kidding about BK, no flames please).
Steven
prev parent reply other threads:[~2003-02-27 15:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-27 3:05 Steven Cole
2003-02-27 13:28 ` Horst von Brand
2003-02-27 15:17 ` Steven Cole [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=1046359032.6616.271.camel@spc9.esa.lanl.gov \
--to=elenstev@mesatop.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vonbrand@inf.utfsm.cl \
/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
all inboxes | Powered by JetHome®