[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070604225038.9973226b.akpm@linux-foundation.org>
Date: Mon, 4 Jun 2007 22:50:38 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: "Nitin Gupta" <nitingupta910@...il.com>
Cc: "Adrian Bunk" <bunk@...sta.de>,
"Richard Purdie" <rpurdie@...nedhand.com>,
"Daniel Hazelton" <dhazelton@...er.net>,
LKML <linux-kernel@...r.kernel.org>,
"Hugh Dickins" <hugh@...itas.com>,
"Nick Piggin" <nickpiggin@...oo.com.au>,
"David Woodhouse" <dwmw2@...radead.org>
Subject: Re: [PATCH -mm 0/5] LZO and swap write failure patches for -mm
On Tue, 5 Jun 2007 11:00:05 +0530 "Nitin Gupta" <nitingupta910@...il.com> wrote:
> Andrew, Andrian,
>
> If you really have the opinion of not going for major cleanups,
> optimizations outside of original LZO code (basically a fork), then
> there is no point in me continuing this work.
err, my LZO attention span ran out 200 emails ago.
> If you think otherwise, please let me know and I will post a newer
> version with improvements from all these feedback I got.
>
I'd say go with the cleanups. The code I've seen is going to be quite
unmaintainable by any kernel developer.
Any fixes which come from upstream can be trivially applied by taking the
diffs against the version of upstream we started with and manually applying
them to our version. If the diffs are too large and complex for that then
a) we shouldn't be merging the code in its current state anyway and b) with
the code as-is we couldn't effectively review or changelog those diffs, so
we shouldn't apply them.
So just fork it and freeze it.
(And please never top-post when working with kernel people).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists