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:59:15

Folks --

I don't have anything new to say to this specific post, but I did want
to say that today has been most excellent in terms of feedback for us.
I thank you all for your time in writing this all down and sending it
to us; every post is being read. It has certainly caused a lot of
discussion on our side.

On Jun 15, 2005, at 3:24 PM, Matthew Knepley wrote:

> Benjamin Allan <baallan_at_[hidden]> writes:
> I would like to emphasize Ben's point about integration.
> I really could care less whether the implementation works right now
> or not. However, I care very much how the build system functions,
> since that it where the hard work of integration will be. You are
> making my job harder by restricting the source. I think the fears
> of allowing access to buggy code are far overblown. I develop an
> open source package with thousands of users and always allow access
> to the latest code. Most people do not even upgrade to the latest
> release, let alone dive in and test out alpha code.
> Thanks,
> Matt
>> Just a brief response on two points (lest the 'insiders' think
>> there are no sympathetic outsiders...).
>> On Wed, Jun 15, 2005 at 01:09:27PM -0400, Jeff Squyres 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.
>> 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".
>> 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. 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)?
>> 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.
>> thanks,
>> Ben
>> _______________________________________________
>> users mailing list
>> users_at_[hidden]
> --
> "Failure has a thousand explanations. Success doesn't need one" -- Sir
> Alec Guiness
> _______________________________________________
> users mailing list
> users_at_[hidden]

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