[Openib-windows] Branding

[Fab Tillier]

> 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.

> > 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.

> > > > 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.

Thanks,

- Fab