After writing my previous message about the subject, I have other
thoughts.

The problem, which triggered the mutiny discussions, is the fact that
Linus was not always prompt in accepting bugfix patches.  So some
subsystems remained buggy (even if there was no dispute which bugfix patch
to accept).  As a result, the 2.4.* kernel series earned the nickname
"Kernel of Pain".

Today, the official policy is that 2.(2n).* series are for bugfix patches,
and 2.(2n+1).* series are for new features.  But Linus himself didn't
follow this policy religiously.

I suggest to change the method of operation, so that two kernel
development processes will go in parallel.  One of them, to be managed by
Linus himself, and it will concern itself with new features, with
directing the future of kernel developments.  Also, non-obvious bug fixes
would go into it (I mean those fixes, which need judgement by Linus).

The other process will concern itself with bug fixes and stabilization of
Linus' kernel.  Essentially, it would be an outgrouth of what the
Distributions are already doing.  People would test the kernel, apply
patches and tinker with it until it is stable.

Once in a while, the products of both processes will be merged together: 
Linus will take a stable kernel and start accepting new-development
patches against it, discarding the previous (unstable) kernel from the
development series.  After a while, people will start a kernel
stabilization process from Linus' work. 

The differences, relative to today's 2.(2n).* vs. 2.(2n+1).* approach
would be:
1. At any moment of time, there will be both stabilizing and development
   kernels at the bleeding edge.
2. Linus will concern himself only with development kernels.
                                             --- Omer
There is no IGLU Cabal.  It is being restructured, and people are still
looking for the best way to structure it.
WARNING TO SPAMMERS:  see at http://www.zak.co.il/spamwarning.html


=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to