On Jun 15, 2009, at 9:52 AM, Pavel Shamis (Pasha) wrote:
> We think that the simple & clear answer is: "take the MPI packages
out
> of OFED"
It is not so simple and clear for me after all this discussion on
the thread. Some OFED member want to remove MPIs and some strongly
against it (the same correct for OFED user community too).
It speaks volumes to me that Red Hat has told us -- repeatedly -- that
this is bad software engineering, not what the rest of the Linux
community does, and has specifically asked us not to do it. But yet
we still do. The main objection so far seems to have been "but we
want to include MPI" (the co-development arguments do not make sense
for OFED *distribution*).
As I mentioned previously I sure that this step will push users from
OFED distributions towards vendors packages, like it was before
first OFED release.
Perhaps it's time that we start discussion of how the every vendor has
incompatible/different OFED distributions is far worse than including
MPI. As I indicated earlier, we're back to the bad old days of
mVAPI. This compatibility stuff is confusing enough for those of us
who are in the industry and working with this stuff every day -- can
you imagine being a customer just trying to get a bug fix?
What will you answer on user's question: "How can I install MPI with
OFED support ?" Will you send user to read 10 pages of MPI
Installation FAQ ? :-)
Many customers are in the habit of downloading/installing MPI
manually, anyway, since they want to be on the bleeding edge of
releases (as has been stated on this list). For customers who just
want an MPI that works, a simple installation guide, and/or getting
the MPI's to distribute binaries, and/or having customers download
MPI's from the distros are all viable solutions. In short: these are
all solvable problems.
More specifically: wasn't OFED created to solve the problem of mVAPI !
= mVAPI != mVAPI? If so, it has failed. There are two obvious
solutions (and probably others):
1. Test together and only use the distros to distribute new versions, or
2. Use better packaging such that vendors can *contribute* their own
technology without effectively making (potentially incompatible) forks
of OFED.
--
Jeff Squyres
Cisco Systems
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
