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 directions.
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 alternative approach.
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 btlís and orte, and I donít know if this will also require something like this between the btlís 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