[Bug 246387] Review Request: libibcommon - OpenFabrics Alliance InfiniBand management common library

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: libibcommon - OpenFabrics Alliance InfiniBand management common library


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246387


dledford at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Review Request: libibcommon |Review Request: libibcommon
                   |                            |- OpenFabrics Alliance
                   |                            |InfiniBand management common
                   |                            |library




------- Additional Comments From dledford at redhat.com  2007-07-03 00:31 EST -------
That can be added, but needs to be added by upstream.  The spec file is
autogenerated from the actual code repo, so any changes to the spec file that
aren't done in the upstream repo would be lost.  In the actual tarball is the
file libibcommon.spec.in that is used to generate the actual spec file.

Yes, www.openfabrics.org is the right URL.  The lack of mention of this
particular package is because they really don't talk a lot about the individual
packages on their web site, they tend to only talk about their largish (40MB+
src.rpm) Open Fabrics Enterprise Distribution, which includes this package and
about 15 others in one single src.rpm.  To see how that rpm builds out, look at
http://people.redhat.com/dledford/Infiniband/openib/1.2/1.el5/ and see for
yourself just how much crap they pack into one rpm.  I didn't think that was
suitable for Fedora, so I'm breaking it back out into individual rpms based upon
their git repos with properly crafted spec files (in terms of BuildRequires: and
such, little details they get to skip entirely by putting it all into one rpm)
and then pushing the changes upstream.  The maintainer of the repo that this
package comes from has accepted my changes in, but that doesn't mean he's gotten
around to making any official releases of this package separate from the larger
conglomerate package yet.  Hence why the URL doesn't say much about this
package, but only talks about their mondo package instead.

As for the git snapshot, I created a make.dist script for the person that
maintains this repo, and that script will spit out either a libibcommon-git.tgz
file or a libibcommon-%{version}.tgz file and tags the version in the repo and
does some other checking.  It's not my place to spit out that versioned, tagged,
official tarball, and since he doesn't have any up on the web site outside of
the mondo rpm, I created this with a git snapshot.  Once we've worked through
the review process and have things on track, I'm going to be helping the
upstream maintainer through the process of becoming a Fedora contributor and
then through the process of taking over the maintenance of this package.  He can
readily create the official tarball and official release package instead of a
git snapshot where as I can't.

As for the static library, that's a common request of the people that make use
of this code.  The customers I here from most are people running anywhere from
256 to 8000 node clusters with Infiniband hardware and they have been requesting
we make static libs available.

Thanks for the suggestions on the reviewing, I'll make sure and do those things
in the future.

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.