You can remove this item...
>>>10) EVMS (Enterprise Volume Management System) (EVMS team)
>>>http://sourceforge.net/projects/evms
>>
>>Sounds like 2.7.x material, viro pointed out several problems ...
>
>
> This one's a problem. LVM1 is dead, so either LVM2 or EVMS are needed to
> avoid a major functional regression vs 2.4...
A political regression only... if EVMS is not good enough for inclusion
in mainline, vendors can merge it and/or LVM2 to avoid problems. _We_
have higher standards for quality :) If no LVM is ready for 2.6.x, we
have no LVM. It's that simple... If no one has stepped up to clean up
LVM1, and LVM2 and EVMS are not ready for inclusion, there's not much we
can do about it. That's _not_ a reason to merge crap...
>>>14) USAGI IPv6.
>>>
>>>Yoshifuji Hideyaki points out that ipv6 is very important overseas
>>>(where some entire countries make do with a single class B ipv4
>>>
>>>address range). He says:
>>>
>>>>Well, our IPsec is ready, runs and is tested...
>>>>ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/
>>>
>>The USAGI guys have been slowly splitting up their patches and
>>submitting them... AFAIK DaveM is just waiting on more split-up IPv6
>>patches from them...
>
>
> Okay, ARE the Usagi IPV6 patches and Dave's work dovetailing into one project?
> I'll happily collate them if so, I'd just like to hear it from one of the
> principal authors...
I'm sure he can elaborate, but AFAIK DaveM and Alexey are only doing
IPSEC... where USAGI and IPSEC intersect, there will be clashes. So if
USAGI is waiting on IPSEC to submit more patches, things are waiting on
DaveM. But if there are IPSEC-independent patches, USAGI should go
ahead and send them :)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/