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

[Agustín Benito Bethencourt <agustin benito codethink co uk>]

Hi Jonathan,

I told you through IRC some days ago I was going to answer this mail and it has taken me too long. Apologies.

On Monday, 19 November 2018 13:46:27 GMT Jonathan Maw via BuildStream-list wrote:
> On 2018-11-13 15:52, Agustín Benito Bethencourt via BuildStream-list 
> wrote:
> > Hi,
>
> [snip]
<snip>
> 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.

I agree with you that the release cycle of the plugins will be different from BuildStream core. What I think 
will be good is to tight the deprecation process to the BuildStream core release process. This simplifies 
things for users, although maybe not for developers. If there is a strategy we can define that benefits both, 
then we should consider it.

> 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.

Although I do not share your concern when it comes to increasing the barrier to contributors as you do, since 
we can apply measures and support plugin authors, you definitely have a point I overlooked. It might be not 
just possible but convenient for technical reasons to have several plugins in a single repo (if I read you 
correctly). 

Re-reading the process above, I think that the following step should be modified

- ** Move the deprecated plugin repository to the buildstream-deprecated-plugin subgroup.
+ ** Move the deprecated plugin to the buildstream-deprecated-plugin subgroup.

The above leaves open if the plugin is in a single repo or in a share repo, I think. Do you see any other 
step that would benefit from clarification? 

Best Regards

-- 
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd
We respect your privacy.   See https://www.codethink.co.uk/privacy.html