[Openib-windows] Branding

[Yossi Leybovich]

> -----Original Message-----
> From: Fab Tillier [mailto:ftillier at silverstorm.com] 
> Sent: Wednesday, October 19, 2005 6:36 PM
> To: 'Yossi Leybovich'; openib-windows at openib.org
> Subject: RE: [Openib-windows] Branding
> 
> 
> > From: Yossi Leybovich [mailto:sleybo at mellanox.co.il]
> > Sent: Wednesday, October 19, 2005 2:12 AM
> > 
> > > From: Fab Tillier [mailto:ftillier at silverstorm.com]
> > > Sent: Wednesday, October 19, 2005 12:10 AM
> > >
> > > Folks,
> > >
> > > I just checked in changes to brand the binaries created when 
> > > building this code as OpenIB binaries rather than any particular 
> > > vendor.
> >
> > As I recall we agreed on COPMANY_NAME environment variable that by 
> > default will change to be "OpenIB". (I also sent you patch that do 
> > that for wsd installer.) After we agreed that each company 
> will need 
> > to maintain its own inf files, why not to let each company 
> that would 
> > like supply binaries to give it own version,company name 
> and product 
> > name.
> 
> Customers don't want vendor provided binaries for the core 
> components - there's no way to tell if vendor X's release is 
> compatible with Vendor Y, even if they both claim that their 
> binaries are OpenIB code.  The core in this case is at a 
> minimum the access layer, the HCA drivers, IPoIB, SRP, and 
> WSD.  OpenSM probably belongs in there too, but that's up to 
> Mellanox to make that call.
>  

I don't argue about what customers want (maybe our customers are different
from yours) but simply suggest a way to satisfy all of us.
If the default environment variables will be "OpenIB alliance" etc. then on
clean OpenIB build you got the same result as you want ,and still give the
option to Mellanox (and other companies that want to create binaries for
them self and their customers) to have their own signature of product
version etc.

About portability that issue that each vendor that supply its binaries need
to solve.


> I am going to build binaries and post them on the 
> windows.openib.org web server for anyone to use, with the 
> expectation that all vendors will package these up in their 
> releases.  See the email I sent last week after the OpenIB 
> board meeting when the board agreed this was a good idea.
> 

That really good idea and you right the signature should be OpenIB alliance 
I still did not figure who/how you control the version number (like when we
change the major release number ?)

> Since the core binaries will have the SVN repository version 
> information, it will be easy for customers to identify any 
> interoperability issues they might encounter.
> 
> Lastly, if you do want a vendor branded solution, you can 
> modify the versioning file in your repository - presumably 
> you also have other changes you haven't put back into the SVN 
> repository, so you're already managing two trees that are out 
> of sync.  If the trees are in sync, what are you gaining by 
> applying your own version information aside from confusing 
> the customer?


That exactly what I want to avoid , I want to be identical to the OpenIB as
much as possible ( including ics_ver.h file)
The only changes from OpenIB that I want in my release should be from real
reasons (like bugs that OpenIB did not patch yet)

> 
> > > This affected any component that used to
> > > include ics_ver.h, which has been renamed oib_ver.h and 
> picks up the 
> > > SVN revision through the VER_OPENIB environment variable 
> (which must 
> > > be set or build will fail).
> >
> > Why not to let companies to decide on their version calling 
> mechanism 
> > and keep default to the OpenIB. I would prefer to see 4 
> numbers with 
> > environment variables, 3 numbers are the release number 
> (i.e. 1.2.0 ) 
> > and the last one is the SVN number
> 
> You can version your private binaries however you like - 
> there's nothing preventing you from having your own version 
> numbers, company, and product names in your private 
> repository.  However, they will not be official OpenIB 
> binaries if you do so.
> 

I agree , but I suggest that versions will be different, still the sources
will be identical in all files that we did not touch.

> - Fab
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20051019/bb5c075e/attachment.html>