Then they haven't read the source code. I have, and it is almost
completely uncommented from my point of view - I don't think
you've started commenting code unless you have at least one line of
comment per function point/complexity point, and the linux kernel is
below that number by at least a factor of five. That shows especially
in the networking code, which is very complex and very undercommented.
It's where almost any predictor would predict bugs to lie.
Any kind of attention paid to comments are welcome, in that sense. I'm
very happy that someone's at least gone through the comments, and added
documentation bugs instead of code bugs for a change! Maybe the
maintainers of the code will now fix the comments in light of the bugs
introduced by other people who couldn't understand their comments well
enough to fix them right!
> What they do not understand is:
>
> 1. Why are changes which are of a non-technological origin being
> allowed to be made. Particularlly when those changes do break
Because they're less harmful than changes which are of a technological
nature. This is the classical spiral risk model at work: at this stage
there is little risk involved in fixing the comments, and a lot to gain.
The code looks more presentable as a result, and still works the same.
Maybe somebody'll fix the alignments next :-). That's sure to break
something.
> previous functioning code and applications. Changing documentation
> is one thing, changing source code and comments is a total
> different matter.
Comments, NOT source code, is what is being talked about.
> 2. Why is someone, other than the author/maintainer, making changes
> to the source code and the comments contained in the source code.
Because they're perfectly free to. There is no really vertical
hierarchical development model here. Anybody is free to submit patches by
and large. They can attack the maintainer with the patches, or they can
attack Linus directly with them. Going through the maintainer is
classical vertical propogation. Through Linus it's kind of top-down
:-). Or they can publish the patch and wait for it to be adopted or
changed, which will be horizontal propagation. If patches propogated by
whatever means get accepted and they're good, OK. If they get accepted
and they're bad, they'll be corrected pretty damn soon as soon as
someone else sees them!
> 1. They view this as a capricious act and internal critics of Linux,
Then they're crazy. Point blank crazy. Or they don't understand the
development model (well, neither do I completely, but then neither
does anybody completely ..).
> The internal critics are using the incident as an example that
> the opensource community is not a peer review of source code
> but a one person crusade to correct spelling and grammar errors
> with disregard for the original intent of the author/maintainer
> and for what it breaks.
Then they're disregarding the fact that the spelling changes HAVE been
peer reviewed and HAVE been uncorrected where appropriate. That will
continue to happen.
When changes occur in linux, that is not indicative of either good or
bad things happening, just indication of where the current evolutionary
focus is. The code area spotlighted will evolve, guided by Linus, who
weeds out obvious errors, and peers who weed out and correct other
errors.
> The supporters are unable to guarantee to those internal critics
> that is type of event will not happen again.
Well, why would they? In fact, I can guarrantee it WILL happen again.
Changes get published, reviewed and unmade and made again, but all
subject to review. There is no guaranteee of monotonic progress.
> The spelling and grammar corrections have no technological merit
> in their point-of-view.
Don't they want documentation? Great!
> They see an antithetical position between RedHat Linux Distribution
> 5.1 which has a language option of "redneck" and the spelling and
Don't get this, but then I haven't seen the redneck Locale. Is this
like valspeak or jive and other semi-serious thinsg done over the years
... ?
> GNU GPL'ed, freeware, etc, in a corporate environment.
Mmm .. tell them from me that they aren't exactly thinking straight!
> Terry L. Ridder
> Blue Danube Software (Blaue Donau Software)
> "We do not write software, we compose it."
---------------------------------------------------------------------
Peter T. Breuer MA CASM PhD (Ing.), Prof. Asoc.
Area de Ingenieria Telematica E-mail: ptb@it.uc3m.es
Dpto. Ingenieria Tel: +34 (9)1 624 99 53
Universidad Carlos III de Madrid Fax: +34 (9)1 624 94 30/65
Butarque 15, Leganes/Madrid URL: http://www.it.uc3m.es/~ptb
E-28911 Spain
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu