On May 27, 2014, at 2:28 PM, George Bosilca <bosi...@icl.utk.edu> wrote:
> On Tue, May 27, 2014 at 5:09 PM, Ralph Castain <r...@open-mpi.org> wrote: >>> That being said, I agree with Ralph on the fact that accepting them in >>> the trunk doesn't automatically qualify it for inclusion in any >>> further stable release. However, if ORNL setup nightly builds to >>> validate their module, I'm pretty certain nothing will stay against >>> their inclusion in some future release. >> >> I strongly disagree - we've discussed this at length before, and the issue >> of release schedule coordination is a deal buster. If people think it >> helpful to have their component in the devel trunk, I can somewhat absorb >> that one. > > There is no such coordination issue in this particular case, as we > don't coordinate with their releases. They maintain their component, > check for the right version of their software and enable their > component if every requirement is fulfilled. Ah, but we do have to coordinate George. The scenario we encountered in this before was when someone needed to make a change in their component because of a change in their corresponding system. So the pressure mounted to generate a release from OMPI that would contain that revision - but that raised further issues. Was this a "bug" fix that could go in a stable series, as requested? How did we deal with their schedule vs ours in terms of what version of OMPI works with what version of their software? Been thru this with Slurm (when we added some specific OMPI-support into Slurm) and it was a terrible problem. Finally had to break the connection at the end of 1.6 as both sides were too frustrated to continue it. It was just too hard to keep track of what version of Slurm worked with what version of OMPI, explaining and helping users to figure out the combinations, etc. Now, that said - in these cases, we have a much smaller version of that problem. Only one STCI site (plus you folks in a less-critical role), and no HPX sites (outside of a couple of academic researchers) at this time. So coordination may indeed be something we simply offload to them - they can keep track of version-to-version matching at that small scale. > >> Adding them to a release is a non-starter with me. > > On which base are you making this assessment? This is a community > based project, if one of the members of the community undergo the > effort to develop and validate a specialized component and if they > engage to follow up on the bug reports on their work, I don't see any > valid ground we can forbid them from including their module on a > stable release. I agree that we have similar issues with other 3rd party libraries, and it has been interesting to watch the recent issues with MOFED on the user list in that regard. In some ways, I guess we could consider it in a similar light and argue that the coordination with RTE release mirrors things like OFED. Our current dependencies are on broader community libraries that undergo slow rates of change, not on independent libraries, and that does make some degree of difference. We also have never been asked to coordinate with those libraries - at least, not yet, though this entire discussion raises the question of "if we do it for them, then why not for others?". So maybe you have the right approach to that issue. Let the contributing member wrestle with the woes of coordinating their releases on their end, with the RM on this end having the right to say "no" to pressures regarding schedule and/or modifications to stable release branches. Sadly it will definitely make the RM's life even harder as these pressures aren't always easy to resolve...but that will be the next guy's problem :-) Will have to ponder more and hopefully deal with it if/when it becomes an issue. Your comments definitely sparked the thinking, though, so thanks! Ralph > > George. > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/05/14871.php
