[openfabrics-ewg] Re: How to generate IBED releases using 1.0branch

[Shawn Hansen (shahanse)]

As far as communicating our plans to the openib-general: 
 
I'd like to request the development lead(s) to draft a technical summary
of a) what components are going to be included in IBED; b) how it
relates to the main OpenFabrics release; and c) any other information we
feel the community would like to see.
 
I'll then edit and craft a broader message based on this core material.
 
--Shawn

________________________________

From: openfabrics-ewg-bounces at openib.org
[mailto:openfabrics-ewg-bounces at openib.org] On Behalf Of Sujal Das
Sent: Wednesday, March 29, 2006 8:12 AM
To: 'bos at pathscale.com'; Tziporet Koren
Cc: Michael S. Tsirkin; 'Openfabrics-ewg at openib.org'
Subject: Re: [openfabrics-ewg] Re: How to generate IBED releases using
1.0branch



Communicating to open fabrics general - the proposal was for the
nominated chair, Shawn, to do so. 

-----Original Message----- 
From: Bryan O'Sullivan 
To: Tziporet Koren 
CC: Michael S. Tsirkin; Openfabrics-ewg at openib.org 
Sent: Wed Mar 29 08:00:45 2006 
Subject: [openfabrics-ewg] Re: How to generate IBED releases using 1.0
branch 

On Wed, 2006-03-29 at 16:54 +0200, Tziporet Koren wrote: 

>      1. Any module that is already in the kernel will be taken from 
>         the git tree that is targeted for 2.6.17 
>
(http://www.kernel.org/git/?p=linux/kernel/git/roland/infiniband.git;a=s
ummary) 
>         This include the following: mthca, ipath (if I understand it 
>         should be in soon), core (all modules), ipoib, srp 
>      2. Kernel modules that are not in Linux kernel will be taken from

>         these directories: 
>         iSER, SDP - from the trunk 
>         RDS: from SilverStorm contrib directory (till they move it to 
>         the trunk) 

Sounds good to me. 

>      1. All user space code will be taken from the 1.0 branch. I will 
>         send all user space patches that are important for this 
>         release. If it's OK I can also check them in, or ask the 
>         maintainers as agreed to do so. 

I think the best thing to do is send patches, then commit to svn after 
say a day's delay in case anyone objects. 

>      1. MPI: 
>         MVAPICH - tarball is provided by Mellanox 

Why would we not want to build MVAPICH from SVN? 

>         Open MPI - tarball is provided by Cisco 

I'm reluctant to just use a tarball without any visibility into what's 
happening in its development.  Can we at least have a pointer to where 
the Open MPI development tree is, be it SVN or CVS or whatever? 

> I think this module can help us to progress both OpenFabrics and IBED 
> releases very well and also contribute for the stability of code that 
> is going to Linux kernel. 

Yep. 

> BTW - when do we go public to OpenFabrics general list? 

This should really have happened by now.  I'd like someone to put 
together a draft announcement, circulate it here, and then send it to 
openib-general once it's been whipped into shape. 

        <b 

_______________________________________________ 
openfabrics-ewg mailing list 
openfabrics-ewg at openib.org 
http://openib.org/mailman/listinfo/openfabrics-ewg 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20060329/8ecd1c45/attachment.html>