phk at phk.freebsd.dk
Mon May 22 01:37:15 PDT 2006
In message <20060522080255.GB730 at turion.vk2pj.dyndns.org>, Peter Jeremy writes:
>I totally agree. My concern is the (apparent) lack of a formal process.
Blunt speaking time:
The reason why we don't have a more formal process is that whenever we
try that, it does not work.
The main reason it does not work is that whenever some feature is
put on notice, a number of very vocal people will come out defending
exactly that feature as the only reason the world still exists etc.
Eventuallyy, somebody will grudingly say "I'll take responsibility
for this code".
And then nothing continues happen.
And the old code is still sitting there festering in the tree, preventing
us from progressing with far more important stuff.
Then after some timeout, the issue is brought up again, and the cycle
Until at some point, somebody gets sick and tired of it, and either A)
walks away and says "let somebody else fix TTYs" or B) nukes the code
In other words: PCVT did follow our formal process, but it's taken so
long that people have forgotten about it.
So If we are to have a (more) formal process, it will have to be
formal in both directions.
In the case of PCVT this would have been amounted to:
"Fix PCVT to be SMP locked, do the right things with TTYs,
work with whatever is the state of the art in keyboards.
And do so before August 1st OR ELSE".
Now, in your own mind, think for a moment what would have happened
if I had sent that email out...
The inherent conflict between the users who "just want it all to
keep working forever" and the developers who have "very limited
time to push shit around", there will always be that conflict in
an un(der)funded open Source project.
In the end, the developers will always win, one way or another
(for 10 points: prove this by induction).
It follows logically that the only way to be sure to keep any given
piece of code alive is to become a developer and maintain it yourself.
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the cvs-src