linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Thomas Winischhofer <thomas@winischhofer.net>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, jsimmons@infradead.org
Subject: Re: 2.6.1-mm1: drivers/video/sis/sis_main.c link error
Date: Sun, 11 Jan 2004 18:58:22 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.58.0401111502380.1825@evo.osdl.org> (raw)
In-Reply-To: <3FFF79E5.5010401@winischhofer.net>



On Sat, 10 Jan 2004, Thomas Winischhofer wrote:
> 
> The whole framebuffer stuff in 2.6 is ancient. (Look at the file dates.)

Note that the fb stuff is ancient because it's basically not maintained as 
far as I'm concerned.

I occasionally get huge drops from James, and they invariably break stuff. 
Which means that I often decide (espcially when trying to stabilize 
things) that I just can't _afford_ to apply the fr*gging patches. Because 
by past experience applying one of the big "everything changes" patches 
tends to break more things that it fixes.

I'm sorry, but this i show it is.  The fbcon people have been changing 
interfaces faster than they have been fixing bugs in the code. Together 
with the fact that most of the development seems to happen in outside 
trees, and nobody ever sends me fixes relative to the released tree, this 
makes for a pretty bad situation.

I really think that development should happen in the regular tree, or at 
least be synched up in reasonable chunks THAT DO NOT BREAK everything.

I realize that some fb developers seem to disagree with me, but the fact 
is, the way things are done now, fb will _always_ be broken. Most people 
for whom the standard kernel works will never test the fb development 
trees, so those trees will never get any amount of reasonable testing. As 
a result, they WILL be buggy, and synching with them WILL be painful as 
hell.

There is a d*mn good reason for why development should happen
incrementally, and in the standard trees, and not in some outside tree. 
For one: testing. For another: figuring out when things break in a timely 
manner.

		Linus

  reply	other threads:[~2004-01-12  3:25 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-09  9:40 2.6.1-mm1 Andrew Morton
2004-01-09 14:47 ` 2.6.1-mm1 Christoph Hellwig
2004-01-09 14:53 ` 2.6.1-mm1 Wojciech 'Sas' Cieciwa
2004-01-09 14:21   ` 2.6.1-mm1 Bartlomiej Zolnierkiewicz
2004-01-09 15:24 ` 2.6.1-mm1 (compile stats) John Cherry
2004-01-09 16:30 ` 2.6.1-mm1 Prakash K. Cheemplavam
2004-01-09 21:20   ` 2.6.1-mm1 Andrew Morton
2004-01-09 21:24     ` 2.6.1-mm1 Prakash K. Cheemplavam
2004-01-09 23:04     ` 2.6.1-mm1 - nforce2 timer patch sum up cheuche+lkml
2004-01-09 19:31 ` 2.6.1-mm1: sound/pci/cmipci.c compile error Adrian Bunk
2004-01-09 22:43   ` Andrew Morton
2004-01-09 23:37 ` 2.6.1-mm1: drivers/video/sis/sis_main.c link error Adrian Bunk
2004-01-10  4:04   ` Thomas Winischhofer
2004-01-12  2:58     ` Linus Torvalds [this message]
2004-01-12  4:53       ` Gene Heskett
2004-01-12  5:42         ` Andrew Morton
2004-01-12  6:11           ` Valdis.Kletnieks
2004-01-12  6:47             ` Gene Heskett
2004-01-12  7:05               ` Andrew Morton
2004-01-12  7:20                 ` Gene Heskett
2004-01-12 12:38                 ` Gene Heskett
2004-01-12  6:21           ` Gene Heskett
2004-01-12  6:34             ` Andrew Morton
2004-01-12  6:58               ` Gene Heskett
2004-01-12  7:03               ` Gene Heskett
2004-01-12 16:33             ` Dave Jones
2004-01-12 17:00               ` Gene Heskett
2004-01-12 17:04                 ` Dave Jones
2004-01-12  8:58       ` Thomas Winischhofer
2004-01-12 14:32         ` Moritz Muehlenhoff
2004-01-12 10:36       ` Andrew Walrond
2004-01-13 19:04     ` Adrian Bunk
2004-01-14  0:35       ` Thomas Winischhofer
2004-01-15 11:32         ` Adrian Bunk
2004-01-15 11:42           ` Thomas Winischhofer

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=Pine.LNX.4.58.0401111502380.1825@evo.osdl.org \
    --to=torvalds@osdl.org \
    --cc=akpm@osdl.org \
    --cc=jsimmons@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thomas@winischhofer.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).