search

inveniosoftware / invenio

Invenio digital library framework
https://invenio.readthedocs.io
MIT License
623 stars 291 forks source link

RFC invenio-* component naming #3666

Open kaplun opened 8 years ago

kaplun commented 8 years ago

Problem

Invenio is made of:

Following an implicit convention, services such as INSPIRE, have already created some Invenio components calling them invenio-foo, to mean that the foo functionality is implemented as an extension for Invenio and can be installed on a given Invenio installation. However not being developed by the Invenio core team, such component doesn't necessarily follow the development process of the Invenio core components (e.g. linear commit history, e.g. git tags with message, e.g. 1.0.0a* versioning, e.g. ...).

The above convention has the drawback that when such component arrives on Pypi, it might not look immediately clear, to the inexperienced eye, that such service component hasn't followed the same development process of a core component, and that, albeit apparently branded as Invenio is not necessarily endorsed by the Invenio core developers.

How should a service keep on contributing to Invenio by developing Invenio components?

Proposals

  1. No longer naming service components with the invenio- prefix. It will no longer be clear that the component requires Invenio and is extending it, but at least there is no branding/policy issue.
  2. Add service specific prefixes, such inspire-*. As above, although it has the further downside of making such a component less appealing to externals, since one would believe that it works only for a given service even if it is not necessarily true.
  3. Keep using the invenio- prefix albeit making it clear on Pypi who endorses the components (how?) (e.g. ala Flask, where there are blessed and non blessed extensions: http://flask.pocoo.org/extensions/)
  4. Have all invenio-* components, thus including service ones, hosted under Inveniosoftware and thus following Invenio core components development policies (thus software oriented policies, rather than service oriented ones).
  5. Have components initially born under each service umbrella, following each service policy, and when maturity arises and the component is already well used, transfer it under Inveniosoftware organization for making it following also development policies of Invenio core components.
  6. More?
kaplun commented 8 years ago

cc: @inveniosoftware/triagers see also #3665

david-caro commented 8 years ago

Any of these can be also mixed with using a special prefix for external components, like 'invenio-ext' or similar, until they are officially supported and moved into inveniosoftware. That might help clarifying what is and what is not official.

jirikuncar commented 7 years ago

How should a service keep on contributing to Invenio by developing Invenio components?

All Invenio components are developed by "services". Hence, all service contributions are welcome as long as they don't break existing functionality, are reasonably configurable, and include tests.

  1. No longer naming service components with the invenio- prefix. It will no longer be clear that the component requires Invenio and is extending it, but at least there is no branding/policy issue.

The invenio- prefix is in ideal world mark of generic reusable component for digital repositories. If it is not possible then IMHO the <service>- prefix is preferable.

  1. Add service specific prefixes, such inspire-*. As above, although it has the further downside of making such a component less appealing to externals, since one would believe that it works only for a given service even if it is not necessarily true.

If the component doesn't depend on service then the invenio- prefix is preferable for visibility and the package can live under inveniosoftware-contrib organization.

  1. Keep using the invenio- prefix albeit making it clear on Pypi who endorses the components (how?) (e.g. ala Flask, where there are blessed and non blessed extensions: http://flask.pocoo.org/extensions/)

It would be nice if all invenio- packages on PyPI have multiple maintainers and general inveniosoftware for emergency purposes.

  1. Have all invenio-* components, thus including service ones, hosted under Inveniosoftware and thus following Invenio core components development policies (thus software oriented policies, rather than service oriented ones).

It should be no question that packages under Inveniosoftware follow common development policies, which of course evolve over time by strong cross-service maintainers team.

  1. Have components initially born under each service umbrella, following each service policy, and when maturity arises and the component is already well used, transfer it under Inveniosoftware organization for making it following also development policies of Invenio core components.

The "packagebirth" might not always go according to plan. The transfer can happen in almost any maturity state as long as the common style is followed. We do not discriminate based on origin!