Could we stop fix^wbreaking this stuff please. GCC 3.2.2:
arm-linux-gcc -Wp,-MD,arch/arm/kernel/.asm-offsets.s.d -D__KERNEL__ -Iinclude
-Wall -Wstrict-prototypes -Wno-trigraphs -Os -fno-strict-aliasing -fno-common -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mapcs-32 -D__LINUX_ARM_ARCH__=4
-march=armv4 -mtune=strongarm110 -mshort-load-bytes -msoft-float -Wa,-mno-fpu -Uarm -nostdinc -iwithprefix include -DKBUILD_BASENAME=asm_offsets -DKBUILD_MODNAME=asm_offsets -S -o arch/arm/kernel/asm-offsets.s arch/arm/kernel/asm-offsets.c
In file included from include/asm/system.h:28,
from include/asm/bitops.h:22,
from include/linux/bitops.h:3,
from include/linux/thread_info.h:20,
from include/linux/spinlock.h:12,
from include/linux/capability.h:44,
from include/linux/sched.h:7,
from arch/arm/kernel/asm-offsets.c:15:
include/asm/proc-fns.h:128:39: missing terminating ' character
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
> Could we stop fix^wbreaking this stuff please. GCC 3.2.2:
>
> include/asm/proc-fns.h:128:39: missing terminating ' character
Ah, but the 'real' fix is to never use a word which requires an
apostrophe - E.G.
I can't apply this patch -> I can not apply this patch
Russell's patch -> The patch which Russell wrote
:-)
John.
On Wed, Mar 05, 2003 at 11:10:15AM +0000, Russell King wrote:
> Could we stop fix^wbreaking this stuff please. GCC 3.2.2:
> ...
> include/asm/proc-fns.h:128:39: missing terminating ' character
100% agreed. People really are going too far IMO.
Given that most people will never read those comments, the
effort would be much better spent proof-reading/correcting
documentation than comments.
The "its just a spelling mistake, it cant break the build!"
mantra is also way off base. If you touch a .c/.h file, you
introduce the possibility of breakage.
The cant -> can't pedantry is an example of just how extremely
silly these are getting. Is there really someone who sees
"cant" and doesn't understand what it could mean?
It just pedantic masturbation AFAICS.
Dave
Hi All,
Where can I get a full documentation on the memory management (for
linux)?
thanks & regards
Prasad Kamath
There was a guy who had done this thesis on documenting the Linux VM. He
posted an announcement on this list, I think it was in last dec
sometime. Check the archive.
On Wed, 2003-03-05 at 12:37, Prasad Kamath wrote:
> Hi All,
> Where can I get a full documentation on the memory management (for
> linux)?
>
>
> thanks & regards
> Prasad Kamath
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
_________________________________________________________________________
Terje Eggestad mailto:[email protected]
Scali Scalable Linux Systems http://www.scali.com
Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal +47 975 31 574 (MOBILE)
N-0619 Oslo fax: +47 22 62 89 51
NORWAY
_________________________________________________________________________
> Hi All,
> Where can I get a full documentation on the memory management (for
> linux)?
>
>
> thanks & regards
> Prasad Kamath
>
Take a look at http://www.csn.ul.ie/~mel/projects/vm/
Cheers
---------------------------------------------
This message was sent using M-Web Airmail - JUST LIKE THAT
M-Web: S.A.'s most trusted and reliable Internet Service Provider.
http://airmail.mweb.co.za/
On Wed, 5 Mar 2003, John Bradford wrote:
> Ah, but the 'real' fix is to never use a word which requires an
> apostrophe - E.G.
>
> I can't apply this patch -> I can not apply this patch
> Russell's patch -> The patch which Russell wrote
Thank you, Commandar Data.
(although he seems to have picked up the ability to use them later in the
series)
:D
this is an interesting document. do you know anything
similar to this for kernel VFS?
thanks
parviz
--- Bongani Hlope <[email protected]> wrote:
> > Hi All,
> > Where can I get a full documentation on the
> memory management (for
> > linux)?
> >
> >
> > thanks & regards
> > Prasad Kamath
> >
>
> Take a look at
> http://www.csn.ul.ie/~mel/projects/vm/
>
> Cheers
>
> ---------------------------------------------
> This message was sent using M-Web Airmail - JUST
> LIKE THAT
> M-Web: S.A.'s most trusted and reliable Internet
> Service Provider.
> http://airmail.mweb.co.za/
>
>
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
On Wed, 5 Mar 2003 09:12:37 -0800 (PST)
pd dd <[email protected]> wrote:
| this is an interesting document. do you know anything
| similar to this for kernel VFS?
|
| thanks
| parviz
| --- Bongani Hlope <[email protected]> wrote:
| > > Hi All,
| > > Where can I get a full documentation on the
| > memory management (for
| > > linux)?
| > >
| > >
| > > thanks & regards
| > > Prasad Kamath
| > >
| >
| > Take a look at
| > http://www.csn.ul.ie/~mel/projects/vm/
See the collection of linux filesystem user and implementation URLs
at <http://www.xenotime.net/linux/linux-fs.html>.
Updates welcome.
--
~Randy
On Wed, Mar 05, 2003 at 11:22:12AM +0000, John Bradford wrote:
> > Could we stop fix^wbreaking this stuff please. GCC 3.2.2:
> >
> > include/asm/proc-fns.h:128:39: missing terminating ' character
>
> Ah, but the 'real' fix is to never use a word which requires an
> apostrophe - E.G.
>
> I can't apply this patch -> I can not apply this patch
I can not apply this patch == I am able to not apply this patch
I cannot apply this patch == I am not able to apply this patch
If you are going to correct something be careful of changes
in meaning.
> Russell's patch -> The patch which Russell wrote
Assumes data not in evidence. Russel might have composited
the patch. Try "The patch from Russel" or "The patch Russel
provided" I would honestly be willing to have just "Russels
Patch", "Russel patch" or "patch a la Russel" to evade the
tortured language for avoiding the possesive.
In any case, if it doesn't make the text more clear what is
the point?
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
On Wed, 2003-03-05 at 05:20, Dave Jones wrote:
> On Wed, Mar 05, 2003 at 11:10:15AM +0000, Russell King wrote:
>
> > Could we stop fix^wbreaking this stuff please. GCC 3.2.2:
> > ...
> > include/asm/proc-fns.h:128:39: missing terminating ' character
>
> 100% agreed. People really are going too far IMO.
> Given that most people will never read those comments, the
> effort would be much better spent proof-reading/correcting
> documentation than comments.
>
> The "its just a spelling mistake, it cant break the build!"
> mantra is also way off base. If you touch a .c/.h file, you
> introduce the possibility of breakage.
That is why I was very careful with my its -> it's patch.
In the two files where an extra apostrophe would have broken
the build, I changed its to it is. Why not just leave it alone?
Because some well-meaning spelling fixer may come along in the
future and break it, just like in proc-fns.h.
>
> The cant -> can't pedantry is an example of just how extremely
> silly these are getting. Is there really someone who sees
> "cant" and doesn't understand what it could mean?
> It just pedantic masturbation AFAICS.
>
> Dave
It's too bad that the cant -> can't change is tarred with the same brush
as thresold -> threshold and asociation -> association. My belief is
that those kind of fixes have these benefits:
The comments are more readable.
The source can be grepped more accurately.
Correct spelling sets a good example.
Incorrect spelling sets a bad example and proliferates.
Why all the fixes now? Because it's a window of opportunity. Linus
seems more comfortable with accepting these kind of changes now than at
other times.
If we don't get these changes in now, expect to have this same
conversation around 2.9.50 or so. (Assuming that 3.0 will follow 2.6)
Cheers,
Steven
On Wed, Mar 05, 2003 at 05:50:27PM -0800, jw schultz wrote:
> > Russell's patch -> The patch which Russell wrote
>
> Assumes data not in evidence. Russel might have composited
> the patch. Try "The patch from Russel" or "The patch Russel
> provided" I would honestly be willing to have just "Russels
> Patch", "Russel patch" or "patch a la Russel" to evade the
> tortured language for avoiding the possesive.
And on the subject of spelling fixes, can I call you j schult? 8)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
> > Russell's patch -> The patch which Russell wrote
>
> Assumes data not in evidence. Russel might have composited
> the patch. Try "The patch from Russel" or "The patch Russel
> provided" I would honestly be willing to have just "Russels
> Patch", "Russel patch" or "patch a la Russel" to evade the
> tortured language for avoiding the possesive.
>
> In any case, if it doesn't make the text more clear what is
> the point?
Err, it was a joke :-)
John.
On Wed, 2003-03-05 at 13:03, Terje Eggestad wrote:
> There was a guy who had done this thesis on documenting the Linux VM. He
> posted an announcement on this list, I think it was in last dec
> sometime. Check the archive.
>
>
> On Wed, 2003-03-05 at 12:37, Prasad Kamath wrote:
> > Hi All,
> > Where can I get a full documentation on the memory management (for
> > linux)?
> >
> >
> > thanks & regards
> > Prasad Kamath
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> --
> _________________________________________________________________________
>
> Terje Eggestad mailto:[email protected]
> Scali Scalable Linux Systems http://www.scali.com
>
> Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE)
> P.O.Box 150, Oppsal +47 975 31 574 (MOBILE)
> N-0619 Oslo fax: +47 22 62 89 51
> NORWAY
> _________________________________________________________________________
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Mel Gorman's thesis. He is/was at Univerisity of Limerick, Ireland. URL
does not always seem to work - sometimes it goes down and comes up a bit
later. Has happened twice to me.
"
The documentation comes in two parts. The first is "Understanding the
Linux Virtual Memory Manager" and it does pretty much as described. It
is available in three formats, PDF, HTML and plain text.
Understanding the Linux Virtual Memory Manager
PDF: http://www.csn.ul.ie/~mel/projects/vm/guide/pdf/understand.pdf
HTML: http://www.csn.ul.ie/~mel/projects/vm/guide/html/understand/
Text: http://www.csn.ul.ie/~mel/projects/vm/guide/text/understand.txt
The second part is a code commentary which is literally a guided tour
through the code. It is intended to help decipher the more cryptic
sections as well as identify the code patterns that are prevalent
through the code. I decided to have the code separate from the first
document as maintaining the code in the document would be too painful
Code Commentary on the Linux Virtual Memory Manager
PDF: http://www.csn.ul.ie/~mel/projects/vm/guide/pdf/code.pdf
HTML: http://www.csn.ul.ie/~mel/projects/vm/guide/html/code
Text: http://www.csn.ul.ie/~mel/projects/vm/guide/text/code.txt
Any feedback, comments or suggestions are welcome from anyone with a VM
interest but I would appreciate if people already familiar with the VM
would even give a brief read to check for technical accuracy. There was
rarely an authoritative source to check to make sure I was right and I
didn't want to be asking questions every 5 minutes on IRC or mailing
lists :-)
"
--
Ranjeet Shetye
Senior Software Engineer
Zultys Technologies
Ranjeet dot Shetye2 at Zultys dot com
http://www.zultys.com/
The views, opinions, and judgements expressed in this message are solely
those of
the author. The message contents have not been reviewed or approved by
Zultys.
On Wed, Mar 05, 2003 at 08:11:11PM -0700, Steven Cole wrote:
>
> That is why I was very careful with my its -> it's patch.
> In the two files where an extra apostrophe would have broken
> the build, I changed its to it is. Why not just leave it alone?
> Because some well-meaning spelling fixer may come along in the
> future and break it, just like in proc-fns.h.
Wait, this sounds like a conversation with the Mafia:
"Pay us protection money."
"Why do we need to pay you for protection?"
"So we can protect you from criminals like ourselves."
I'd rather solve this problem by making standalone spelling fixes and
other cosmetic changes taboo. Cosmetic changes combined with actual
useful code changes are fine with me. If you're risking breaking the
build, there should be some benefit that justifies the risk.
Consider this a vote against standalone spelling/typo patches.
-VAL (normally a total pedant about spelling and grammar)
On Thu, 2003-03-06 at 18:04, Val Henson wrote:
> On Wed, Mar 05, 2003 at 08:11:11PM -0700, Steven Cole wrote:
> >
> > That is why I was very careful with my its -> it's patch.
> > In the two files where an extra apostrophe would have broken
> > the build, I changed its to it is. Why not just leave it alone?
> > Because some well-meaning spelling fixer may come along in the
> > future and break it, just like in proc-fns.h.
>
> Wait, this sounds like a conversation with the Mafia:
>
> "Pay us protection money."
> "Why do we need to pay you for protection?"
> "So we can protect you from criminals like ourselves."
That's a ridiculous comparison and it weakens your argument. Leaving a
potential problem in place rather than fixing it as I did would be the
passive-aggressive approach, not the other way around.
>
> I'd rather solve this problem by making standalone spelling fixes and
> other cosmetic changes taboo. Cosmetic changes combined with actual
> useful code changes are fine with me. If you're risking breaking the
> build, there should be some benefit that justifies the risk.
Breaking the build is a low probability (many hundreds of fixes and one
build break AFAIK) and low consequence failure (a build fix of that
nature is obvious and quickly and easily done).
>
> Consider this a vote against standalone spelling/typo patches.
>
> -VAL (normally a total pedant about spelling and grammar)
The more persuasive argument against tree-wide fixes has been made by
Dave Jones, who has been slowed down by having to reconcile his external
patches with these changes. For that reason, I've suggested that
maintainers use Dan Kegel's scripts to clean up their own areas when the
time is right for them. But the maintainers have better things to do
with their time that this kind of low priority work. So chances are that
the spelling fix situation will go back into hibernation for another
release cycle, which I'm sure will make a lot of people happy.
Steven
> I'd rather solve this problem by making standalone spelling fixes and
> other cosmetic changes taboo. Cosmetic changes combined with actual
> useful code changes are fine with me. If you're risking breaking the
> build, there should be some benefit that justifies the risk.
I generally reject combined patches which clean up and
change functions in places I maintain. The cleanup garbage
makes reviewing harder.
-- Pete
>> Wait, this sounds like a conversation with the Mafia:
>>
>> "Pay us protection money."
>> "Why do we need to pay you for protection?"
>> "So we can protect you from criminals like ourselves."
>
> That's a ridiculous comparison and it weakens your argument. Leaving a
Reductio ad absurdum is often enlightening.
> potential problem in place rather than fixing it as I did would be the
> passive-aggressive approach, not the other way around.
But that's not exactly what you're doing - you're replacing one
(very small) problem with another (very real) problem, the breakage
of people's patches. Fixing up patches because of spelling
errors is a total waste of developer's time.
>> I'd rather solve this problem by making standalone spelling fixes and
>> other cosmetic changes taboo. Cosmetic changes combined with actual
>> useful code changes are fine with me. If you're risking breaking the
>> build, there should be some benefit that justifies the risk.
>
> Breaking the build is a low probability (many hundreds of fixes and one
> build break AFAIK) and low consequence failure (a build fix of that
> nature is obvious and quickly and easily done).
Breaking the build is indeed a low probability (assuming you compile
test your tree). Breaking other people's patches is a high probablility.
M.
On Thu, 2003-03-06 at 20:33, Martin J. Bligh wrote:
> >> Wait, this sounds like a conversation with the Mafia:
> >>
> >> "Pay us protection money."
> >> "Why do we need to pay you for protection?"
> >> "So we can protect you from criminals like ourselves."
> >
> > That's a ridiculous comparison and it weakens your argument. Leaving a
>
> Reductio ad absurdum is often enlightening.
>
> > potential problem in place rather than fixing it as I did would be the
> > passive-aggressive approach, not the other way around.
>
> But that's not exactly what you're doing - you're replacing one
> (very small) problem with another (very real) problem, the breakage
> of people's patches. Fixing up patches because of spelling
> errors is a total waste of developer's time.
Agreed.
>
> >> I'd rather solve this problem by making standalone spelling fixes and
> >> other cosmetic changes taboo. Cosmetic changes combined with actual
> >> useful code changes are fine with me. If you're risking breaking the
> >> build, there should be some benefit that justifies the risk.
> >
> > Breaking the build is a low probability (many hundreds of fixes and one
> > build break AFAIK) and low consequence failure (a build fix of that
> > nature is obvious and quickly and easily done).
>
> Breaking the build is indeed a low probability (assuming you compile
> test your tree). Breaking other people's patches is a high probablility.
So another approach to this is to offer cleanup services to willing
maintainers who don't have the time to do it themselves. If anyone
wants their section of the tree spell-corrected, I can do that with the
help of Dan's scripts (the easy part), and review the resulting diff for
inappropriate fixes (broken puns, changed meaning, broken compiles),
send that around to a small group (the spelling police squad) for
further review, and then send it back to the requesting maintainer, who
can /dev/null it entirely, or hack it up to his delight before sending
it Linuswards.
How's that?
Steven
>> Breaking the build is indeed a low probability (assuming you compile
>> test your tree). Breaking other people's patches is a high probablility.
>
> So another approach to this is to offer cleanup services to willing
> maintainers who don't have the time to do it themselves. If anyone
> wants their section of the tree spell-corrected, I can do that with the
> help of Dan's scripts (the easy part), and review the resulting diff for
> inappropriate fixes (broken puns, changed meaning, broken compiles),
> send that around to a small group (the spelling police squad) for
> further review, and then send it back to the requesting maintainer, who
> can /dev/null it entirely, or hack it up to his delight before sending
> it Linuswards.
>
> How's that?
Sounds great to me, at least ;-)
M.
The current hubub was caused by a build breakage, right?
And that build breakage was caused by a spellfix
outside of a comment.
Simple rules to avoid that problem:
1. don't fix anything not in a comment. (spell-fix.pl doesn't.)
2. build after you fix
3. don't fix any comments in code you can't build
4. don't fix any punctuation at all
The earlier hubub was caused by people worried about
improper fixes (removing puns, changing meaning, etc.)
The simple expedient of having several literate people
(sensitized to all the concerns raised in this thread)
review the change should get rid of most of that risk.
So I don't think the spelling police have to beat a
total retreat. They just have to follow the above
rules of thumb.
Or is the hubub really about something else? Like people
just hate the whole idea, and wish it would go away,
and don't really want to discuss it rationally?
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
You are fixing things and people are giving you shit for it. People who
want evidence that making something better is worth doing before they do
it are.... Sigh. In the unlikely event that Linus doesn't take your
fixes directly, I'll take them for reiserfs, just let me know. ReiserFS
code is as good as we know how to make it, as a matter of policy, and
that includes the comments.
--
Hans
On Thu, Mar 06, 2003 at 11:16:07PM -0800, Dan Kegel wrote:
> Or is the hubub really about something else? Like people
> just hate the whole idea, and wish it would go away,
> and don't really want to discuss it rationally?
Spelling fixes are annoying ways to break patches that provide no
user visible value. It also detracts from the character of the
code: who wants "drain brammage" to be replaced with "brain dammage"?
-ben
--
Junk email? <a href="mailto:[email protected]">[email protected]</a>
Benjamin LaHaise wrote:
> On Thu, Mar 06, 2003 at 11:16:07PM -0800, Dan Kegel wrote:
>
>>Or is the hubub really about something else? Like people
>>just hate the whole idea, and wish it would go away,
>>and don't really want to discuss it rationally?
>
>
> Spelling fixes are annoying ways to break patches that provide no
> user visible value.
Indeed, breaking patches with spelling fixes is a big mistake, and should never be done.
> It also detracts from the character of the
> code: who wants "drain brammage" to be replaced with "brain dammage"?
Nobody. That's why I maintain a spelling police code of conduct at
http://www.kegel.com/kerspell/
along with my spellchecking tools. I explicitly say "Do not fix puns!"
and "Have several literate people review your changes!"
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
On Fri, 2003-03-07 at 17:17, Benjamin LaHaise wrote:
> On Thu, Mar 06, 2003 at 11:16:07PM -0800, Dan Kegel wrote:
> > Or is the hubub really about something else? Like people
> > just hate the whole idea, and wish it would go away,
> > and don't really want to discuss it rationally?
>
> Spelling fixes are annoying ways to break patches that provide no
> user visible value. It also detracts from the character of the
> code: who wants "drain brammage" to be replaced with "brain dammage"?
There is a difference btween plain wrong and misleading text, printing
wrong things to the console, text that confuses non first language
speakers and accidentally removing humour.
Someone broke a little bit of asm and it got fixed. Someone broke
the pnp layer a lot longer before and its still not fixed. You
have regular releases, stuff gets broken now and then.
People are actually *doing* things, give them a break.
On Fri, 7 Mar 2003 23:52:47 -0100 Dave Jones <[email protected]> wrote:
| On Fri, Mar 07, 2003 at 11:15:59PM +0000, Alan Cox wrote:
|
| > > Spelling fixes are annoying ways to break patches that provide no
| > > user visible value. It also detracts from the character of the
| > > code: who wants "drain brammage" to be replaced with "brain dammage"?
| > People are actually *doing* things, give them a break.
|
| There's a shitload of patches in the 2.4 commit archives that
| mostly still apply. With each iteration of spelling fixes,
| it becomes more and more work to weed through these to find
| out if things are really applied or not. In the beginning I
| used Rusty's 'isapplied' script. Its now pretty much useless,
| requiring manual inspection of code on every diff.
|
| Spelling fixes aren't going to get us to 2.6.0 any faster.
| There are _dozens_ of known problems, and I'll take patches
| fixing real problems over spelling fixes any day.
What/where is the "2.4 commit archives"?
Do you want/need any help with this?
--
~Randy
On Sat, 2003-03-08 at 00:52, Dave Jones wrote:
> There's a shitload of patches in the 2.4 commit archives that
> mostly still apply. With each iteration of spelling fixes,
> it becomes more and more work to weed through these to find
> out if things are really applied or not. In the beginning I
> used Rusty's 'isapplied' script. Its now pretty much useless,
> requiring manual inspection of code on every diff.
True enough. What areas is 2.5 paticularly behind on right now,
I've noticed the radio drivers are bit out here and there,
what else is badly behind ?
On Fri, Mar 07, 2003 at 11:15:59PM +0000, Alan Cox wrote:
> > Spelling fixes are annoying ways to break patches that provide no
> > user visible value. It also detracts from the character of the
> > code: who wants "drain brammage" to be replaced with "brain dammage"?
> People are actually *doing* things, give them a break.
There's a shitload of patches in the 2.4 commit archives that
mostly still apply. With each iteration of spelling fixes,
it becomes more and more work to weed through these to find
out if things are really applied or not. In the beginning I
used Rusty's 'isapplied' script. Its now pretty much useless,
requiring manual inspection of code on every diff.
Spelling fixes aren't going to get us to 2.6.0 any faster.
There are _dozens_ of known problems, and I'll take patches
fixing real problems over spelling fixes any day.
Dave
Dave Jones wrote:
> Spelling fixes aren't going to get us to 2.6.0 any faster.
One problem with spelling fixes is that there's never a good
moment, nor a good procedure to do them.
> There are _dozens_ of known problems, and I'll take patches
> fixing real problems over spelling fixes any day.
I guess it would be nice if Linus would give some advance warning
when he's going to accept speelnig fixes. That way, people with
"real work" could schedule a few weeks at the beach, while the
spelling police does its grisly job.
Of course, we all know that this will never happen ;-)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
Werner Almesberger wrote:
> One problem with spelling fixes is that there's never a good
> moment, nor a good procedure to do them.
>
>
>>There are _dozens_ of known problems, and I'll take patches
>>fixing real problems over spelling fixes any day.
>
>
> I guess it would be nice if Linus would give some advance warning
> when he's going to accept speelnig fixes. That way, people with
> "real work" could schedule a few weeks at the beach, while the
> spelling police does its grisly job.
>
> Of course, we all know that this will never happen ;-)
The next best thing might be for the spelling police
to maintain an archive of all the accepted spellfix patches.
That would let a sufficiently motivated person
(say, a spelling policeman) to offer a patch update
service with a reasonable certainty that he could
bring arbitrary patches up to date with respect to
the spellfixes in the main tree.
I've outlined a proposal for this at http://www.kegel.com/kerspell
This spellfix business is way more work than is reasonable.
The people who spend the time making it work while taking
care of all these issues (avoiding pun removal, avoiding
breakage, avoiding wrong corrections, patch updating)
are clearly on acid, but I salute them. Me, I just take
notes and watch :-)
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Dan Kegel wrote:
> The next best thing might be for the spelling police
> to maintain an archive of all the accepted spellfix patches.
At the end of the day, bulk fixes may just be the least evil.
Alternatives like passing all spelling fixes individually through
the appropriate channels for each subsystem would still cause
conflicts, and also burden Linus with lots of re-iterations of
the same theme, coming from many directions and spread over weeks.
A bit of coordination would be useful, though. E.g. I suppose it
would hurt people like Dave Jones (with his 2.4 patch queue) a lot
less if the spelling changes would happen while their queue is
reasonably short.
> This spellfix business is way more work than is reasonable.
It will be easier the next time ;-)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/