search

pmix / pmix-abi

PMIx Headers for ABI Compatibility
BSD 3-Clause "New" or "Revised" License
0 stars 2 forks source link

OpenPMIx vs ABI #12

Closed rhc54 closed 2 years ago

rhc54 commented 2 years ago

We have a bit of a sync problem between what is in OpenPMIx vs this ABI. I understand and agree that the master branch here needs to be that of the Standard. However, we have at least one user who is interested/needs to interface to OpenPMIx, and this master branch doesn't include things that are in the library.

I think the best solution might be to add "openpmix-vx.y" branches here that carry the ABI of the library. I don't see a clean way to do that over in OpenPMIx - I suppose I could fork your repo and modify it locally there.

Any preferences?

rhc54 commented 2 years ago

Sorry I accidentally hit "return" and opened an empty issue. I have updated the initial comment - please take a look and let me know what you think.

jjhursey commented 2 years ago

The PMIx Standard ABI is a subset of the interface provided by OpenPMIx since OpenPMIx naturally moves faster than the PMIx Standard. So the problem you have is that you have a user that wants to essentially use an OpenPMIx ABI since they want interfaces not (yet) in the PMIx Standard. Correct?

Adding a branch to the pmix/pmix-abi specific to OpenPMIx doesn't seem like the right thing to do. It would require the PMIx Standard to maintain it and signify some preference for OpenPMIx (if other PMIx implementations emerge).

My leaning would be for OpenPMIx to fork this repo into their project space and then add the branches there. OpenPMIx could then sync their fork with the upstream PMIx Standard ABI repo and then sync their branches. This would allow OpenPMIx to control the permissions for updating their branches (instead of relying on the PMIx Standard permissions).

rhc54 commented 2 years ago

Yeah, that is the situation. I think that makes the most sense too. I'll create the fork and go from there. Thanks!