+1 (Already said it during review, but figured I'd make it official here.)
Dana Walker Associate Software Engineer Red Hat <https://www.redhat.com> <https://red.ht/sig> On Mon, Jun 18, 2018 at 2:01 PM, Daniel Alley <dal...@redhat.com> wrote: > +1 > > On Mon, Jun 18, 2018 at 12:16 PM, Brian Bouterse <bbout...@redhat.com> > wrote: > >> +1 >> >> On Mon, Jun 18, 2018 at 8:47 AM, Ina Panova <ipan...@redhat.com> wrote: >> >>> +1 >>> >>> >>> >>> -------- >>> Regards, >>> >>> Ina Panova >>> Software Engineer| Pulp| Red Hat Inc. >>> >>> "Do not go where the path may lead, >>> go instead where there is no path and leave a trail." >>> >>> On Thu, Jun 14, 2018 at 10:19 PM, Bihan Zhang <bizh...@redhat.com> >>> wrote: >>> >>>> +1 >>>> I think the plugin_template is very valuable for bootstrapping plugin >>>> development, but we have had issues with keeping it up to date. Creating a >>>> smash test that will enforce this on new PRs make perfect sense to me. >>>> >>>> >>>> >>>> On Thu, Jun 14, 2018 at 11:29 AM, Austin Macdonald <aus...@redhat.com> >>>> wrote: >>>> >>>>> I've recently updated the plugin_template to work with the latest >>>>> master (3.0). [0] The template handles almost all of the bootstrapping >>>>> work necessary to write a new plugin, so it is valuable to keep it up >>>>> to >>>>> date. Given human nature, it's likely that the plugin_template will >>>>> tend >>>>> to fall behind as it did recently. I have some ideas to save time >>>>> while >>>>> keeping the template current and useful. >>>>> >>>>> 1) Move the plugin writer docs [1] into the plugin_template repository >>>>> - Leave a (very) high level overview in the core docs with a >>>>> link to >>>>> the template docs. >>>>> - Plugin writer docs PRs would only go to one place, and it >>>>> would >>>>> be easier keep the docs in line with the code. >>>>> - Narrative docs in the template would explain what needs to >>>>> be >>>>> done generally, linking to the modules. >>>>> - Specific instructions would live in the code modules >>>>> alongside >>>>> basic working code, and additional commented out code >>>>> to demonstrate and explain more complex behaviors. >>>>> >>>>> 2) Add pulp_smash tests for basic functionality of a bootstrapped >>>>> plugin. >>>>> - Run these tests as a check on pulpcore and template PRs >>>>> - Ensure that discoverability works >>>>> - Fail with breaking Plugin API changes >>>>> - If the test uses pulp_smash, it would include a base set of >>>>> integration tests for every new plugin. >>>>> >>>>> My reasoning is that no matter what changes we make to pulpcore, >>>>> we need to keep the plugin writer docs updated. Doing this in the >>>>> template will provide value for plugin writers, and will inform >>>>> pulpcore >>>>> developers when it needs to be updated. >>>>> >>>>> [0]: https://github.com/pulp/plugin_template/pull/9 >>>>> [1]: https://github.com/pulp/pulp/tree/master/docs/plugins/plugin >>>>> -writer >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> Pulp-dev@redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev