[rescue] Linux wet paint, was Re: Spark10 CPU question (must fix - SPARC damnit :-) )

[Meelis Roos]

> Well said, and from my perspective, very true.

Yes, agreed - I liked the wet paint analogue very much.

But I do not see it as "kinds having no discipline" - it's rather a 
different approach taken to the development process to help with scaling 
of development.

In a small and controlled team you can force the focus on some spewcific 
features and polish these features until they are done. But you can not 
scale that model out to lots of developers and lots of features - at 
least not with developer doingit for their own fun.

To scale the scope with enthusiast developers, you can do most of the 
feature development easily but yoiu have to leave the tail of quality 
control to someone more motivated. Linux has selected the model of 
bleeding edge and fast developing upstream kernel that is released when 
it seems good enough to thew developers, and then distribution makers 
try to scale out the testing and stabilization. Some have busoiness 
models that can put more reources into it, some use more crowdsourcing 
for testing, bus ocassionally thre "wet paint" gets though (Ijust saw it 
with container memory management reclaiming problem).

> > > Linux.  There is nothing -really- wrong with Linux. It's a little
> > > utilitarian. Almost too much of a good thing. It's in our TV's and in
> > > our phones. Who thought that was going to happen 20 years ago? It seems
> > > to take up new features pretty quick, and the paint is always a bit wet,
> > > either in the kernel, applications or even within the distribution.  I
> > > think it's always been like that, and I'm not convinced it will ever be
> > > better.  The paint around a feature will cure, but there is always wet
> > > paint somewhere.

-- 
Meelis Roos (mroos at linux.ee)