Nicholas Wheeler wrote:
On Mon, Jul 7, 2008 at 1:46 AM, Andrew Lentvorski <[EMAIL PROTECTED]> wrote:
Even in the case of when I rewrote the rpc.lockd for FreeBSD in the early
5.X series and it was very plainly much better than what currently existed,
I had to do a *lot* of work other than just "write the code." I had to break
it apart; I had to explain it to the person who was going to commit it
(Scott Long-who was both knowledgeable *and* pleasant--a rare combination in
open source--I got very lucky); I had to demonstrate that it worked; I had
to rearrange the code to meet what they considered to be acceptable coding
practice (multiple exit points vs. deep nesting--in this instance the
standard "multiple exit points" was a bad idea and the "deep nesting" was
the good idea--but I had to concede to get it committed).
I'm not sure if I read this correctly...but you conformed to their
wants (demands) to get your software accepted into their repository,
and thus distributed. Why go through all that work?
Quite simply--testing. Getting your code on mainline gets an order of
magnitude (or more) people running it. Even though I was maintaining
that chunk of code, several people found edge cases and usage patterns
that I missed. I never would have found those without the extra users.
e-mail it to them, and if it's good code, they'll use it. It's
especially weird that you changed your code to what you thought was a
bad idea, to get it distributed. Wouldn't you rather have solid code,
filled with good ideas running on your own server, then code that's
not-so-solid, with a few bad ideas, running on everyone's?
The code was functionally the same. The issue is that "deep nesting"
reflects a "state machine" much better for humans than multiple exit
points. You know that everything between "else if (state) {" and "}"
are *exactly* one state and all the side effects are inside.
Unfortunately, many projects having coding guidelines like "8 space
tabs," "80 character lines," and "no deep nesting." In general, that
works fine, but in this particular instance, every time we did a
transform to multiple returns, some piece of a state got forgotten.
Of course, *I* kept the original deeply nested code so when I got a bug
report, I could work it out from the states.
Likewise, if you don't like KDE's unpolished look, you can polish it
yourself and use it yourself. You don't need it to be accepted into
mainstream...if there's one or two bugs that really annoy you, patch
it yourself, for yourself, and distribute the code. If it's good,
it'll be accepted into the main branch by
other_people_who_like_your_work. The important part here is when you
code on open source software, it should be for yourself first and
foremost...and as a side benefit, you give it to other people.
However, there's no reason to run into a brick wall a bunch of times,
and navigate through bureaucracies, just so other people can use your
code. Just use it yourself and be happy you've got a polished
version...if someone asks you for it, just give 'em the patches.
Distributing yourself doesn't work for a variety of social factors.
First, people have to actually *find* your code--most people never knew
how broken all the open-source rpc.lockd's were at the time. They just
knew things like "Don't put mail spools on NFS" when it was "Linux and
FreeBSD have broken locking implementations."
Second, you're not going to get much testing if someone has to pull your
code and recompile their kernel. Why do you think everybody tries to
get even the most obscure drivers pushed into Linus' tree?
Third, the bug reports are very likely to go down the drain--especially
since the main developers will just trash them as "not our code".
Social factors matter.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
