Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2005-06-15 19:56:09

On Jun 15, 2005, at 2:32 PM, Benjamin Allan wrote:

>> Although we have not made a final decision yet, given that community
>> involvement is a *strong* goal of this project, we've actively
>> discussed several models of how to bring the community into Open MPI.
>> One possibility is to have a minimal registration mechanism where
>> anyone who registers can get anonymous/read-only access. This would
>> likely be a suitable deterrent for someone to take our work and claim
>> it as their own (because there would be a paper trail).
> a)
> It has not been my experience that a paper trail makes the
> class of people prone to theivery any less prone to theivery.
> The sad reality of ineffective (totally absent?) quality control by
> journals and conferences makes the deterrent effect unlikely.

It's still a hope that we can cling to. :-)

But just to make clear: this is only one option; no final decision has
been made yet.

> b)
> On the release issue, the '"slow stable" plus snapshots' release
> cycle (after the initial stable point) seems very desirable to me.
> I've lost countless months of time making my primary open-source
> deliverable appear "stable" to the users in spite of deep instabilities
> in external tools I am forced to incorporate for programmatic reasons.


> open-mpi, I can guarantee, will be added to this list of external
> dependencies I have to cope with and I'm thrilled to see folks aiming
> to keep the quality high in the first release.
> What I would like to see, as the developer of another (non-competing)
> infrastructure tool set, is some sort of little web form or at
> least an email link where
> I can put in a description of my project and say why it should be
> given early access, rather than just being told "sorry, closed".

We realize that we excluded people from the alpha. I apologize for
this, but that decision was made mainly for expediency (to get this
thing out out out, it was easier to handle a bunch of well-informed bug
reports from a small number of people) and for the reasons that I cited
in my prior mail.

And honestly, it's probably a good thing that it was closed. OMPI
worked well enough on our development machines, but our test users
found some really embarrassing, stupid bugs as soon as they tried to
run on other machines (as well as a fair number of devious bugs that
didn't show up in our standard regressions). :-)

> It takes time to incorporate a new mpi implementation (and yet
> another set of awful build requirement peculiarities) into a
> a package like mine that is expected to be portable and to cope
> seamlessly with every mpi that comes along.

What is your tool, BTW?

> I can guarantee
> that within days of the open-mpi download becoming public,
> people will be dumping hatemail in *my* mailbox because the
> toolset i support isn't 'open-mpi-ready'.
> As it happens, I can get a bootleg (not necessarily current)
> openmpi tarball from
> someone nearby as I work at Sandia, but that shouldn't have
> to be the case. Wouldn't it be better if (knowing that
> testing comes with certain politeness requirements and testing
> duties) those who have to support open-mpi users get to do
> gamma-testing programming before the release (since beta is closed)?

To clarify: only the alpha was closed.

The beta will be public and has not occurred yet; we're hoping that
it's Real Soon Now (as mentioned previously: we're adhering to the LAM
policy of not promising specific release dates, as they inevitably turn
out to be wrong).

> On the question of 'benefit of more testers' from 'my' class
> of user. You're right, i don't have the slightest interest
> in examining or reporting bugs down in 95% of your code.
> (unless valgrind tells me otherwise...)
> But the 5% of code which the end user (and more importantly
> down-stream build systems) have to see is likely to be
> gone over with a fine-toothed comb.

I agree 100%. I hope my prior mail and the above clarification about
the beta clarify some of the issues and our rationale. I can tell you
that the build system is remarkably similar to that of LAM/MPI's. As
other mails today have indicated, OMPI has fully functional wrapper
compilers (mpicc, mpiCC, mpif77, mpif90) and an ompi_info command
(analogous to, but greatly superseding LAM's laminfo command).

{+} Jeff Squyres
{+} The Open MPI Project