I'm beginning to believe that we need a design meeting specifically
over this question. Too many unknowns exist, with significant
potential problems lurking behind them. Frankly, this issue could have
a major impact on how we operate, performance, and a variety of other
factors going forward - many of which may be difficult to predict.
I suspect there may not be "optimal" solutions to many of these
questions, but there certainly will be strong opinions in multiple
As part of that discussion, I propose that we consider alternative
methods for meeting the same overall objective - namely, reuse of the
BTL's by another software project. For example, a simple copy-and-
branch is the dominant method today, with patches used by both parties
to cherry-pick the changes they want from the other code users.
Multiple tools have been developed to support this mode of operation,
yet we haven't discussed any of them in this context. The proposed
approach contains a number of impacts that may be avoided with an
Without such a meeting, I fear we are going to rapidly dissolve into
email hell again.
On Dec 4, 2008, at 1:07 PM, Eugene Loh wrote:
> Richard Graham wrote:
>> I expect this will involve some sort of well defined interface
>> between the btls and orte, and I dont know if this will also
>> require something like this between the btls and the pml I think
>> that interface is rigidly enforced, but am not sure.
> I'm probably missing the scope of what you're saying here, but it
> raises another question in my mind. Is there today a well-defined
> interface between the BTLs and... anything else? PML or whatever?
> Maybe this comes back to a documentation question: do we (or will
> we) have anything written down that says what a BTL must do, what it
> may rely on, etc.?
> devel mailing list