archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Russell King <>
Cc: Kernel Mailing List <>
Subject: Re: Linux 2.5.75
Date: Thu, 10 Jul 2003 16:25:50 -0700 (PDT)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, 11 Jul 2003, Russell King wrote:
> Absolutely no surprise.  In any case, the long development cycle isn't
> what ARM stuff needs.

Well, nothing really _wants_ a long development cycle. I suspect any 
particular feature taken on its own always wants the shortest possible 
development cycle, and that what ends up happening is just that there are 
a lot of interdepencies and just plain "different" development-cycles.

Which is not a bad thing per se, and pretty clearly is unavoidable. So 
I'm not complaining. It's just a fact of life.

I think that the best way to "solve" the problem is to partially ignore 
it, and I don't think it's a bad thing that we have many different trees, 
and some of them are less strongly coupled to others - exactly to handle 
the inevitable case of release cycle lag.

For example, I absolutely detest the BSD "world" model, which actually 
makes these problems bigger by tying different projects together into one 
tree. I think it's much more important to try to have as much freedom as 
possible, including very much having separate timetables and development 

> Hasn't ever, I'm afraid.  I can't think of any stock kernel which has
> been usable, let alone been compilable for ARM.  Which, IMO, is a pretty
> sorry statement to make.

You see that as a sorry statement, but I don't think it's a failure. Why 
_should_ one tree have to try to make everybody happy? We want to try to 
make it easier to keep the couplings in place by striving for portable 
infrastructure etc, but we would only be hampered by a philosophy that 
says "everything has to work in tree X", since that just means that you 
can't afford to break things.

I'd much rather keep the freedom to break stuff, and have many separate
trees that break _different_ things, and let them all co-exist in a 
friendly rivalry.

And my tree is just one tree in that forest.

So it's not a bug - it's a FEATURE!


  reply	other threads:[~2003-07-10 23:11 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-10 21:14 Linux 2.5.75 Linus Torvalds
2003-07-10 21:35 ` Russell King
2003-07-10 22:26   ` Linus Torvalds
2003-07-10 23:05     ` Russell King
2003-07-10 23:25       ` Linus Torvalds [this message]
2003-07-11 19:59       ` Horst von Brand
2003-07-10 23:30 ` Felipe Alfaro Solana
2003-07-10 23:38   ` Linus Torvalds
2003-07-10 23:46     ` Davide Libenzi
2003-07-10 23:40   ` Robert Love
2003-07-11  0:24     ` Diego Calleja García
2003-07-11  0:49       ` Wade
2003-07-11  7:09 ` Benjamin Herrenschmidt
2003-07-11 10:57 ` Linux 2.5.75 - still can't load aha152x (isapnp) => OOPS schmurtz
2003-07-11 17:53   ` Andrew Morton
2003-07-11 18:04     ` James Bottomley
2003-07-11 18:45     ` schmurtz
2003-07-11 12:30 ` incbin (was: Re: Linux 2.5.75) Geert Uytterhoeven
2003-07-11 12:32   ` Geert Uytterhoeven
2003-07-11 15:46 ` Linux 2.5.75 Oliver Pitzeier
2003-07-11 15:52 ` Linux 2.5.75 (compile statistics) John Cherry
2003-07-12 13:50 ` AMD 53C974 based SCSI adapter (was: Linux 2.5.75) Matthias Andree
     [not found] <>
     [not found] ` <>
2003-07-10 23:55   ` Linux 2.5.75 Andi Kleen
2003-07-11  0:12     ` Linus Torvalds
2003-07-11  0:55       ` Paul Mackerras
2003-07-11  8:42       ` Christoph Hellwig
2003-07-11 10:27         ` Lars Marowsky-Bree
2003-07-11 10:39           ` Christoph Hellwig
2003-07-11 16:52           ` Linus Torvalds
2003-07-11 17:03             ` Arjan van de Ven
2003-07-12 19:20               ` Horst von Brand
2003-07-12 23:17                 ` Jeff Garzik
     [not found] <>
     [not found] ` <>
2003-07-11 21:33   ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).