I sent this message on a thread that I didn't realize wasn't on the list
anymore so I am trimming it and resending it. To avoid offending anyone I
am not refering to the thread that triggered this.
This applies to everyone. any statements in quotes mentioned below are not
intended to be a quote of the people involved, but are instead intended to
summarize an attitude that seems to be common in developers who get into
this situation.
<Soapbox>
Just becouse you have been the person working on a piece of the kernel and
fully understand it and have grand plans for how it should go in the
future still doesn't give you full control over that subsystem. You have
to explain what you are doing and why, just saying 'I know best' doesn't
go over well. Donald Becker had this problem and is no longer the primary
maintainer of network drivers in 2.4+. Dave (I for get the last name but
the networking layer) had this problem for a while, but changed his mode
of operating and has been continuing to contribute. The mess with the VM
system in early 2.4 with Rik was another case, now rik is producing
patches that are being accepted instead of being frustrated that his code
is being tinkered with by 'people who don't know what they are doing' (a
classification that can and does at times include Linus). There have been
many others (Richard with devfs, aa with the VM stuff, I'm sure anyone who
has watched things for a year or so can name a dozen others) and all start
off saying 'here is my monolithic piece please put it in the kernel' and
those that stick around and contribute over the long term learn to say
'here is this small piece, this is what it does, this is why (and if it
doen't fix anything immediatly, this is what I am working towards). You
also need to expect that other people will produce patches that affect
your code. when this happens you need to either accept them, fix them, or
explain exactly what's wrong with them (and saying ' this will be the end
of the world' or 'it doesn't fit the long term plans' without explaining
those long term plans first isn't good enough). If you don't do this then
you get frustrated when other people 'muck up' your subsystem and when
your fixes are ignored by Linus.
Note specificly that IT DOES NOT MATTER how well you know the subject you
are coding if your code doesn't make it into the kernel or gets removed
and replaced by someone elses version that has problems becouse your grand
plan isn't understood. No one person is such a perfect programmer that
their code as above reproach and criticism. I'm not saying leave your ego
at home, but I am saying you need to not let your ego get so large that
you stop accepting corrections and criticisms from others.
</Soapbox>
This is not an attack on anyone and I apologize if I implied attitudes
that people don't think they have. I am attempting to get everyone to
think a little on the subject as it is something that seems to be a
chronic problem in the kernel development community.
David Lang
On Wed, 10 Apr 2002, David Lang wrote:
[soapbox snipped]
In the absence of
a. A formal software development process,
b. Formal requirements documents,
c. A high-level formal design document,
d. Marketing and sales,
e. A formal Quality Assurance, Security Assurance and Performance
Assurance effort,
f. A corporate structure,
etc. ...
I don't think it's reasonable to expect people to behave in a different
manner from the way they currently behave. I've heard this described as
a brutal meritocracy, and organizations that need any of the above to
meet their objectives are free to implement them at their own cost and
to their own (and presumably their customers') benefit.
That said, I think Linux could benefit greatly from some of the above,
in particular c. and e. And the recent debate over printk vs. event logs
would be a non-issue if we had b. and d. -- we'd have both because one
is wonderful for rapid debugging and the other is wonderful for system
administration.
--
M. Edward Borasky
[email protected]
The COUGAR Project
http://www.borasky-research.com/Cougar.htm
If God had meant carrots to be eaten cooked, He would have given rabbits
fire.
My post was intended to make people realize how ti fit into the existing
structure, I am not saying that the structure is fundmentally broken and
needs to be scrapped.
the fundamental existing process has been far more sucessful then the more
formal procedures that are allocated, people just need to realize what is
going on and not expect things to happen that won't.
David Lang
On Wed, 10 Apr 2002, M. Edward (Ed) Borasky wrote:
> Date: Wed, 10 Apr 2002 15:02:46 -0700 (PDT)
> From: "M. Edward (Ed) Borasky" <[email protected]>
> To: David Lang <[email protected]>
> Cc: [email protected]
> Subject: Re: Kernel developer attitudes, a problem to watch for.
>
> On Wed, 10 Apr 2002, David Lang wrote:
>
> [soapbox snipped]
>
> In the absence of
>
> a. A formal software development process,
>
> b. Formal requirements documents,
>
> c. A high-level formal design document,
>
> d. Marketing and sales,
>
> e. A formal Quality Assurance, Security Assurance and Performance
> Assurance effort,
>
> f. A corporate structure,
>
> etc. ...
>
> I don't think it's reasonable to expect people to behave in a different
> manner from the way they currently behave. I've heard this described as
> a brutal meritocracy, and organizations that need any of the above to
> meet their objectives are free to implement them at their own cost and
> to their own (and presumably their customers') benefit.
>
> That said, I think Linux could benefit greatly from some of the above,
> in particular c. and e. And the recent debate over printk vs. event logs
> would be a non-issue if we had b. and d. -- we'd have both because one
> is wonderful for rapid debugging and the other is wonderful for system
> administration.
> --
> M. Edward Borasky
> [email protected]
>
> The COUGAR Project
> http://www.borasky-research.com/Cougar.htm
>
> If God had meant carrots to be eaten cooked, He would have given rabbits
> fire.
>
On items c and e below. These are two of the items that
we (OSDL) are addressing.
While we won't ever produce a formal design document for
Linux we are working toward two documents that will address
a "more formal" design approach for two uses of Linux.
These are the carrier grade and data center working groups.
One of the goals of these groups is to produce a high level
roadmap of features and functionality to address these usage
models. The goal of these documents is to get together
the folks who have an interest in Linux addressing these
market segments and to discover what is missing, what is
already being done (or already done) and to agree to work on
filling the holes using the current process. But just as
important to the corporate user or commercial ISV to come
up with a time line of when we think the various features
will be ready for use. (Note, this might not be integrated
into the base kernel but that is the goal for every thing
that makes sense to integrate.)
On the formal quality assurance. I think that is
a product issue and not a kernel development issue. After
saying that we are trying to automate the testing of
development kernels for both performance and "correctness".
This is using a tool called the Scalable Test Platform (STP)
http://www.osdl.org/STP. The theory is that early feedback on
a patch or kernel version is better than waiting until
the folks who do the distributions fix the problems in
their own product quality assurance test cycle. (And have
6 different fixes in 6 different distributions.)
Tim
On Wed, 2002-04-10 at 15:42, David Lang wrote:
> My post was intended to make people realize how ti fit into the existing
> structure, I am not saying that the structure is fundmentally broken and
> needs to be scrapped.
>
> the fundamental existing process has been far more sucessful then the more
> formal procedures that are allocated, people just need to realize what is
> going on and not expect things to happen that won't.
>
> David Lang
>
>
> On Wed, 10 Apr 2002, M. Edward (Ed) Borasky wrote:
>
> > Date: Wed, 10 Apr 2002 15:02:46 -0700 (PDT)
> > From: "M. Edward (Ed) Borasky" <[email protected]>
> > To: David Lang <[email protected]>
> > Cc: [email protected]
> > Subject: Re: Kernel developer attitudes, a problem to watch for.
> >
> > On Wed, 10 Apr 2002, David Lang wrote:
> >
> > [soapbox snipped]
> >
> > In the absence of
> >
> > a. A formal software development process,
> >
> > b. Formal requirements documents,
> >
> > c. A high-level formal design document,
> >
> > d. Marketing and sales,
> >
> > e. A formal Quality Assurance, Security Assurance and Performance
> > Assurance effort,
> >
> > f. A corporate structure,
> >
> > etc. ...
> >
> > I don't think it's reasonable to expect people to behave in a different
> > manner from the way they currently behave. I've heard this described as
> > a brutal meritocracy, and organizations that need any of the above to
> > meet their objectives are free to implement them at their own cost and
> > to their own (and presumably their customers') benefit.
> >
> > That said, I think Linux could benefit greatly from some of the above,
> > in particular c. and e. And the recent debate over printk vs. event logs
> > would be a non-issue if we had b. and d. -- we'd have both because one
> > is wonderful for rapid debugging and the other is wonderful for system
> > administration.
> > --
> > M. Edward Borasky
> > [email protected]
> >
> > The COUGAR Project
> > http://www.borasky-research.com/Cougar.htm
> >
> > If God had meant carrots to be eaten cooked, He would have given rabbits
> > fire.
> >
> -
> 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/
--
Timothy D. Witham - Lab Director - [email protected]
Open Source Development Lab Inc - A non-profit corporation
15275 SW Koll Parkway - Suite H - Beaverton OR, 97006
(503)-626-2455 x11 (office) (503)-702-2871 (cell)
(503)-626-2436 (fax)