Well - uninformed. I didn't know that the format of the proc outputs
was changed, though I should have picked it up from the discussions. I
was busy (150 exams) and missed it. Changing strings is clearly a
mistake; source code ought not to be changed by somebody trying to fix
spelling! But, that said, it is sometimes not crystal clear where the
line should be drawn. There are/were several spelling mistakes in error
messages, for example, and I can imagine that some of those strings were
shared with non-error-message code, leading possibly to this kind of
error. And of course it is good when the connection is discovered by
this kind of mistake.
> particular, the /proc interface was changed, thus breaking compatibility
> with programs which expected to be able to parse the output of /proc
> files. That's what caused the flames, not the changes in the comments,
> by and large.
Thanks for the information. Incidently, I continue to be nonplussed by
the difficulties people have writing simple parsers, and therefore
mystified by the chorus of complaints that arise when a tool breaks
because of a minor change in the /proc interface. In the first place the
interface should have been documented, but if it isn't the tool writer
should be prepared to read liberally ("read liberally, write
conservatively"). Parsers are very very very easy to write. At worst
one can fall back to yacc (yecch ..). There is no excuse for whining
when the tool breaks: one should look at the change; if it is minor,
the tool should be modified to be more liberal, and thanks; if it is
major, the interface author should be chastized.
> although I personally consider spelling fixes to be a waste of
> everybody's time. Obviously other people have different ideas what they
Wurl, as alen poynted owt, speling misteks ar anoying to thows of us
who kan spel beter, and giv en unprofesionel impresion.
> Because they're perfectly free to. There is no really vertical
> hierarchical development model here. Anybody is free to submit patches by
> and large.
>
> Actually, it's considered bad manners to submit patches to code which
> has an active maintainer without first passing it by the maintainer.
I was trying to indicate that the development model is not contracturally
structured. Indeed, only social norms and Linus' word dictate the
procedures.
> Fortunately Linus usually takes of this step, but given how busy Linus
> is, it's more considerate to pass the patches in front of the maintainer
> first.
Yes, of course. But that is a consequence of things getting slightly
more organized (perhaps temporarily!). It has not always been that way,
and perhaps may not be that way again. Right now, thankfully, there are
a number of very competent people acting as maintainers of distinct
sections of code. But there is no police action awaiting people who
don't pass proposed changes by them!
> It's not legally required, obviously, but it is a courtesy that many
> maintainers ask for and expect. After all, the maintainers have often
Exactly.
> made a long-term commitment to maintain and support the code, often
> not to the person who submits a "hit-and-run" patch to the code in
> question. Hence, making a patch without consulting the maintainer,
> especially when the net result makes life harder for the maintainer
I was not suggesting that one should bypass the maintainer. Only
pointing out that in practice sometimes (say 20% of the time) it
happens. The reason may be perhaps, temporary unavailibility of the
maintainer, ignorance by the poster, misdrections in the source, etc.
etc.
> (i.e., introduces bugs or incompatibilities), is really a really
> impolite and socially unacceptable thing to do.
That reminds me, I must wash more often :-).
> - Ted
>
> P.S. See Eric Raymond's "Homesteading the Noosphere" paper for more
> comments about the sociological aspects of free software:
I haven't seen it. I'll look for it.
> http://earthspace.net/~esr/writings/homesteading/
Peter ptb@it.uc3m.es
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu