On Tue, 18 Jan 2005 17:11:50 +0000, Tim Cutts wrote: > > On 18 Jan 2005, at 4:06 pm, Patrick Caulfield wrote: > >> On Tue, Jan 18, 2005 at 03:46:18PM +0000, Tim Cutts wrote: >>> >>> On 17 Jan 2005, at 5:42 pm, Bastian Blank wrote: >>> >>>> On Mon, Jan 17, 2005 at 09:28:56AM +0000, Patrick Caulfield wrote: >>>>> lvm2 - in active development, upstream helpful but often >>>>> busy. >>>>> device-mapper - largely stable. occasional releases. >>>>> lvm10 - stable. no more upstream development at all. >>>>> lvm-common - native package. small number of bugs need sorting >>>>> out >>>>> multipath-tools - in active development, upstream very helpful. >>>> >>>> I'm interrested onm co-maintaining lvm2 and device-mapper. >>> >>> As am I - we use these heavily on some fairly serious kit at work, so >>> I >>> can justify the time... co-maintaining sounds like a sensible thing to >>> do. >>> >> >> So how about you three co-maintain lvm2 & devmapper (and maybe >> lvm-common ? it's >> as much part of LVM as the lvm2 package really), and I'll hang onto >> lvm10 & >> multipath. > > Sounds good to me. I'll be able to help you with testing > multipath-tools too; that and lvm2 are the principal bits we use (we > don't use Debian device-mapper stuff because we build our own kernels > from scratch) > > We use this stuff on both IA64 (HP rx4640) and i386 (HP DL360/380, > mostly) architectures to talk to our dual-fabric SAN (HP StorageWorks > HSV110 controllers on the back) > > How should we coordinate this? >
My recommendation would be an LVM alioth project, w/ a svn or arch (preferred) repository. I've kept track of lvm2 stuff in arch for a number of years, it has worked well. Patrick, it might even be worth all 4 of us maintaining all the LVM related packages (throwing lvm10 in with the rest), since Tim uses multipath-tools, and none of us care much for lvm10. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
