On Thu, 21 Mar 2013 14:31:08 -0400
Stephen Gallagher <sgallagh(a)redhat.com> wrote:
<..>
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
* Union of build-time dependencies. They will grow with every new provider
and make it more difficult hacking only on one 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
We somewhat mix the above approaches: the "big" providers (in the terms of
code base as well as dependencies) are being shipped separately, the rest is
thrown in the universal "providers" repository. The plan is to separate a
provider that would grow "too much" and/or require specific workflow or
release cycle.
Cons:
* Hard on distro packagers (many packages to maintain)
On the contrary: one big tarball would make having multiple packagers of the
OpenLMI components more difficult.
* 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.
We will welcome any new contributor who would want to join the OpenLMI team.
However whoever is interested in developing their own provider can do that in
a different upstream and we're still interested in collaboration.
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).
A provider should be maintained by someone who understands the particular
technology domain the provider takes care of. Wherever (s)he decides to: in
"their" upstream, joining OpenLMI project with a new repository, merging the
provider into one of the existing OpenLMI repositories... Let the software
authors choose.
3) We create a new set of "contrib" providers with its own
community.
One of the options.
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.
I'd leave it up to the contributors to decide how and where they want to
manage the code and focus on the "presentation" side and QE to ensure the
components work together well and the project looks consistent from outside.
Thanks and regards.
--
Tomáš Smetana
Platform Engineering, Red Hat