Re: [BuildStream] Move Docker source plugin out of bst-external

[Jonathan Maw <jonathan maw codethink co uk>]

On 2018-11-13 15:52, Agustín Benito Bethencourt via BuildStream-list 
wrote:
> Hi,

[snip]

> ### Deprecation process
>
> Assuming we have the following stages:
> * roadmap definition
> * development/deployment
> * release
> * maintenance
>
> I haven't put enough thought on this but I would say that the process
> might be something like:
>
> Roadmap
>
> * The deprecation should be proposed and approved following the
> roadmap definition process.
> ** Include the transition plan and technical considerations for
> current users of the plugin to be deprecated.
> * Once approved, the deprecation plan will be communicated to the
> wider community, as any other roadmap item including:
> ** Information on the README file of the affected repos about the 
> deprecation.
> ** Information on the affected Gitlab repo descriptions about the 
> deprecation.
>
> Development/Deployment
>
> * The deployment will be communicated (availability for master users)
> including:
> ** A link to the technical documentation about the plugin.
> ** Link to the description of the plugin published on the web
> (BuildStream in Detail[1] page).
>
> Release
>
> * The BuildStream release, including the ability to use the new plugin
> will include:
> ** Reference to the new and deprecated plugin in the release 
> announcement
> ** Descriptions, including links, of the deprecated and new plugin,
> including an explicit reference to the deprecation of the plugin.
> ** Move the deprecated plugin repository to the
> buildstream-deprecated-plugin subgroup.
>
> Maintenance
> * Identification of those issues and WP MR related with the deprecated
> plugin. Close them before moving tickets to the new milestone.
>
> The above process might seem complex initially but we already have
> some of the above processes in place, so this only adds a couple of
> steps which, by the way, will not be much different from what I am
> working on as new roadmap process in that specific stage. The idea is
> to use the above process as a plan for now and validate it with these
> first plugins deprecation.
>
> What do you think of the above?

Hi Agustin,

Most of this looks good to me, but I have a couple of concerns.

1. Tying the release cadence to buildstream
-------------------------------------------

I think it makes sense to have some plugins tied to buildstream's 
release cadence (e.g. the ones that are currently inside buildstream), 
but I think this would be a larger burden than is required for plugins 
from bst-external. At the moment, we don't guarantee (though are pretty 
good with) stability for plugins from bst-external.

2. One project per plugin
-------------------------

I think creating a project for every plugin is pretty heavyweight, both 
in administrative overhead (to add a new plugin, you need to create a 
new project, assign permissions for maintainers, configure CI, etc.) and 
code-wise (adding the config files for testing, documentation, 
installation, etc.).
These are all things that might end up out of sync with each other.

Also, it increases the amount of overhead it requires to import each 
plugin, e.g.

With multiple plugins per project, configuring a project to import them:
```
plugins:
- origin: pip
  package-name: bst-plugins-containers
  sources:
    docker: 0
    oci: 0
```

With one plugin per project, configuring a project to import them:
```
plugins:
- origin: pip
  package-name: bst-plugins-docker
  sources:
    docker: 0
- origin: pip
  package-name: bst-plugins-oci
  sources:
    oci: 0
```

My main concern is that it would be a barrier to contribution - 
bst-external currently gets a lot of its plugins by people opening up a 
Merge Request and agreeing to create MRs if it stops working. I think 
requiring a project for every plugin would raise the barrier quite 
significantly.

Thanks,

Jonathan

--
Jonathan Maw, Software Engineer, Codethink Ltd.
Codethink privacy policy: https://www.codethink.co.uk/privacy.html