-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
A topic that came up today in an offline meeting was that of how we want to package and maintain the source of the various OpenLMI providers.
Currently, we are maintaining a separate git repository and source tarball for the networking, storage and proxy providers, while all of the others are lumped into the openlmi-providers repository and tarball.
We should really decide on one approach for packaging OpenLMI. I see several options:
1) We ship all OpenLMI providers as a single tarball
Pros: * Less effort for distro packagers and new contributors to locate all of the OpenLMI work. * Keeps all providers co-located with other providers whose models may provide or require dependencies. * Single build-system
Cons: * Single version for all components means that all need to have a version bump and re-release for changes in any provider
2) We ship all OpenLMI providers as separate tarballs
Pros: * Clear separation of functionality * Can release updates to individual providers on their own schedules
Cons: * Hard on distro packagers (many packages to maintain) * Code sharing requires more effort
Furthermore, we need to discuss what to do with providers that exist out of our original designs. If we choose either of the above, how do we handle requests for new providers such as realmd (or future projects that want to add a CIM provider)?
1) We incorporate them into the OpenLMI project directly, using whichever approach we decide on above.
2) We ask them to ship their provider as part of the source of the external project (e.g. as part of the realmd upstream).
3) We create a new set of "contrib" providers with its own community.
My personal opinion would be for us to aim for shipping all providers (both those that originate within the OpenLMI project and those that are contributed from outside) as a single tarball and repository. This to me gives the best experience to the developers and packagers of the software, as they have only a single location to manage. It will also tend towards lending itself to better integration, as there will not be a repository-level barrier hiding the availability of other models from the developer.
Comments and arguments are most welcome.