From: Dave Chinner <david@fromorbit.com>
To: James Bottomley <James.Bottomley@suse.de>
Cc: linux-scsi <linux-scsi@vger.kernel.org>,
linux-ide <linux-ide@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, dm-devel@redhat.com,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Combined storage tree
Date: Mon, 13 Sep 2010 12:58:07 +1000 [thread overview]
Message-ID: <20100913025807.GD411@dastard> (raw)
In-Reply-To: <1284213316.2986.7.camel@mulgrave.site>
On Sat, Sep 11, 2010 at 08:55:16AM -0500, James Bottomley wrote:
> On Sat, 2010-09-11 at 18:20 +1000, Dave Chinner wrote:
> > On Fri, Sep 10, 2010 at 01:27:27PM -0500, James Bottomley wrote:
> > > One of the requests from LSF10 in August was the production of a
> > > combined storage tree. This is now ready at
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/storage-tree
> > >
> > > It's actually a nightly built merge tree consisting of
> > >
> > > scsi-misc; scsi-rc-fixes
> > > libata#upstream-fixes, libata#upstream
> > > block#for-linus, block#for-next
> > > and the dm quilt (which is empty at the moment).
> > >
> > > I haven't yet added vfs or any of the fs trees, but if necessary, I can.
> > >
> > > Note, because it's built nightly, like linux-next, it's hard (but not
> > > impossible) to use it as a basis for git trees (it is much easier to use
> > > it as a basis for quilts).
> >
> > Hmmm. I was kind of hoping for an upstream maintainer tree, kind of
> > like the netdev tree. I really don't see a tree like this getting
> > wide use - if I enjoyed the pain of rebasing against throw-away
> > merge trees every day, then I'd already be using linux-next....
>
> Well, to be honest, that's what people wanted when the issue was raised
> at LSF10. However, unlike net, storage has never had a single
> maintainer, so it's a bit more political than just doing that by fiat,
Bah. Technical arguments win here, not politics. Besides, what
possible political concern can anyone have about using a different
upstream tree for development? A storage maintainer tree would not
replace anyone's little fiefdom; what we need is an integration point
long before stuff gets to Linus....
> plus not all of the current maintainers with storage trees were there.
If that's the barrier to discussion, then where else but a dedicated
storage workshop are you going to get a more representative sample
of storage developers in the same room?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2010-09-13 2:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-10 18:27 Combined storage tree James Bottomley
2010-09-11 8:20 ` Dave Chinner
2010-09-11 13:55 ` James Bottomley
2010-09-13 2:58 ` Dave Chinner [this message]
2010-09-13 16:46 ` James Bottomley
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=20100913025807.GD411@dastard \
--to=david@fromorbit.com \
--cc=James.Bottomley@suse.de \
--cc=dm-devel@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.