[Openib-windows] Branding

[Yossi Leybovich]

> -----Original Message-----
> From: Fab Tillier [mailto:ftillier at silverstorm.com] 
> Sent: Wednesday, October 19, 2005 7:47 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 10:23 AM
> > 
> > > From: Fab Tillier [mailto:ftillier at silverstorm.com]
> > > Sent: Wednesday, October 19, 2005 6:36 PM
> > >
> > > > 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.
> 
> By customers I meant the OpenIB user community - which has 
> been very clear that they do not want vendor specific stacks 
> for the core.  We don't want vendor stacks, and enabling that 
> in the code goes against the goals of OpenIB. However, you 
> can make modifications internally to your code repository to 
> change the branding however you see fit.
> 
> Just because some binaries have the OpenIB branding and 
> versioning information doesn't prevent anyone from packaging 
> them up under a different release version.
> 
> Anyhow, let me look into this a bit more, but honestly I 
> think there are more important things to do.  My goal with 
> this change was to enable the creation of standard and 
> official OpenIB binary releases against the OpenIB SVN 
> repository, and as such the changes enable that.  Just to be 
> extra clear on this, any binaries that aren't branded as 
> OpenIB builds and publicly available are not true OpenIB 
> binaries, but rather derivatives of the OpenIB Windows project.
>  
> > > 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 ?)
> 
> Right now since the SVN trunk is under "gen1", the major 
> version number is 1. The minor number is zero just because we 
> have to start somewhere.  We can define a process by which 
> major and minor version numbers are changed, but this can 
> wait until we need it.
> 

One more little thing don't you think it better to put the SVN version var
in last number (VER_FILEREV(


> > > 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)
> 
> BTW, this changed to oib_ver.h
> 
> > The only changes from OpenIB that I want in my release 
> should be from 
> > real reasons (like bugs that OpenIB did not patch yet)
> 
> Ok.  I want us all to be very careful that we don't apply a 
> patch and create a vendor release and then stop putting 
> pressure to apply that patch (or its
> equivalent) to the trunk.  This applies to both patches and 
> features added to the core.


That the state that we in Mellanox standing now. We need the IPoIB patch and
the CR MAP patch 
We need them for our release and they still did not come in to the OpenIB.

> 
> > > > > 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.
> 
> If you do this, please make sure you clearly state what 
> version of the OpenIB binaries your release is compatible with.

We will do that .
> 
> Thanks,
> 
> - Fab
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20051019/4e9a4442/attachment.html>