[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f73f7ab80909230701k438be273y1e363a9ef5579e4d@mail.gmail.com>
Date: Wed, 23 Sep 2009 10:01:09 -0400
From: Kyle Moffett <kyle@...fetthome.net>
To: Christoph Hellwig <hch@...radead.org>
Cc: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
lars.ellenberg@...bit.com, arjan@...radead.org, lmb@...e.de,
jens.axboe@...cle.com, neilb@...e.de, James.Bottomley@...e.de,
linux-kernel@...r.kernel.org, drbd-dev@...ts.linbit.com,
akpm@...ux-foundation.org, bart.vanassche@...il.com,
davej@...hat.com, gregkh@...e.de, kosaki.motohiro@...fujitsu.com,
torvalds@...ux-foundation.org, nab@...ux-iscsi.org,
knikanth@...e.de, philipp.reisner@...bit.com, sam@...nborg.org,
Mauelshagen@...hat.com
Subject: Re: [GIT PULL] DRBD for 2.6.32
On Wed, Sep 23, 2009 at 07:57, Christoph Hellwig <hch@...radead.org> wrote:
> On Mon, Sep 21, 2009 at 08:51:32PM -0400, Kyle Moffett wrote:
>> You have to realize that this project is NOT a new one, it's been
>> around quite a decent number of years (since kernel 2.2-ish). Yes,
>> the ABI is unique and has its warts, but there are a lot of things
>> that depend on it.
>
> So? That's never been an argument. Quite contrary, we ignored upstream
> for years and fucked up out of tree but please merge anyway is almost
> a counter-argument.
That's not what happened with DRBD at *all*. It was a large project
that ignored upstream for a while yes... but recently they decided to
do things right and submitted all of their patches for review and
comments. After a good number of review cycles during which they were
model citizens for making big necessary changes, nobody could find
anything technically wrong with the code.
Now people are asking the out-of-tree project to continue to maintain
their otherwise-perfectly-merge-ready patchset while also implementing
a bunch of MD/DM/RAID-integration code. Meanwhile several of the
DM/MD RAID guys who *already* have their code upstream have not been
having much luck defining a usable userspace API for the proposed
integrated configuration model.
At the very least, the code is at the point where Greg KH could easily
merge it into staging:
* The code is under GPLv2
* The goal of the developers is to get it merged in the near future
* It builds properly on x86
* It's for a new feature (not an existing one)
* There's a reliable point-of-contact for the code
The only thing missing is a list of exactly what still needs to be
fixed. I see a lot of handwaving about "We want a new API", but
nobody defining what the requirements for that are. If nobody can
figure that out yet, then I see no reason it shouldn't be mainline
mergeable; both Neil Brown and Jens Axboe seem to think this is ready
to merge as well.
Cheers,
Kyle Moffett
--
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