www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Open Source, Cold Shoulder (fwd)
Date Tue, 12 Oct 2004 19:34:09 GMT
El mar, 12-10-2004 a las 10:50 -0700, Justin Erenkrantz escribió:
> --On Wednesday, October 13, 2004 1:21 AM +0800 Niclas Hedhman 
> <niclas@hedhman.org> wrote:
> > I am sure that the upper-tier of ASF would shiver at the thought that hordes
> > of people can gain direct access to the repositories. They/we will dust of
> > the same arguments of why Wiki won't work. But it does. Why? Because *most*
> > people *want* it to work.
> Baloney.  Code review is *essential*.  For httpd, we require *three* people to 
> sign off on any change before it gets merged into the stable branch.  We take 
> our responsibility for providing stable software *extremely* seriously.  We're 
> not about to deploy untested (and unreviewed) fixes to the general population. 
> It would not bode well on our personal reputations or of our software's. 
> Therefore, we're also extremely cautious about adding new committers.
> Furthermore, for example, lots of people suggest patches to httpd.  They think 
> their patch is right.  But, more often then not, their patches are incorrect 
> because they aren't as familiar with the code as the committers are.  If you 
> turned the httpd repository into a wiki-style free-for-all, it would be an 
> extreme uphill battle to keep the code clean because it would turn into 
> anarchy.  The current committers won't be able to keep up and the code would 
> degenerate as everyone throws in what they think is right without having any 
> mandatory review process in place.
> An ex post facto review process (CTR) isn't always acceptable for 
> production-grade software because the reality is that real people can't keep 
> up with a high volume!  CTR works well only when you have a stable core of 
> people whom you trust - as httpd does for its unstable branch, but even then 
> we still use RTC for our stable branches because we want to be 
> as-certain-as-we-humans-can-be that our fixes are right before we merge them 
> into stable.

You can separate both functions, i.e. development or patching and code
review/quality control. The linux kernel is beginning to be a good
example, where you have:
- Linus (vanilla) tree as a reference value (think Fed Reserve)
- Andrew Morton (mm) patches, making it a higher risk (think Dow Jones)
- Full preemption and other special or highly experimental patches
(think Nasdaq or even Hedge Funds)
- Hardware manufacturers trying to get their code in, to get more wide
support for their hardware.
- Other people suggesting improvements around (I've sent three typos
recently) just because they don't want to maintain their needed pieces.

Redhat, Mandrake, Suse, Debian, Gentoo, etc. all fish in the stock
market, providing que QA you meant, (like the big investment banks,
BTW). In some senses, the linux kernel is becoming a very large stock
exchange, and it requires two different abilities: the ability to
recognise good patches from bad ones, and the ability to convince and be
a good leader.

If you look at lkml.org it is fascinating to see how the market is at
work. On top of this list you have the different distros lists and

The position of Linus requires him to play a very subtle balance between
all the "exchange" members. Other players can be more peripheral but
strong (see Ben H. for the PPC kernel, or Rusty Russell for the network

> I believe the quality of the code base is in direct proportion to the effort 
> required to get commit bits and what it takes to get a change in.  There are 
> projects here in ASF-land that don't care at all about actual users and are 
> willing to leave them in the lurch due to petty political battles.  That's not 
> the spirit of open source I care about or want the ASF to support.  -- justin

IOW, if some people wants to use apache code as a base and start
delivering patched versions (mostly like vanilla + patches in the kernel
case), they can use the repository and/or patches in the lists and issue
system with no problem.

The fact that the kernel bazaar is so dynamic is explained out of raw
size, high modularity and variation of architecture and function, from
handhelds and solid state wireless routers to highly multiprocessor NUMA
machines. Yesterday I sent a fix (1) which worked for me, just corrected
from one (2) which I imagine worked in the SMP #ifdef, but not in my

(1) http://lkml.org/lkml/2004/10/11/274

(2) http://lkml.org/lkml/2004/10/11/111

None of them have been picked by the mm or any other aggregation, which
means they will be rediscovered by other people eventually... or
rendered useless by a refactoring of the code.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
Santiago Gala <sgala@hisitech.com>
High Sierra Technology, SLU

View raw message