Re: [Pulp-dev] Importer Name

I was one of the voices of dissent on this but I am more of a -0/+0 than a -1. David On Fri, Mar 23, 2018 at 2:56 PM, Dana Walker wrote: > FWIW, I've looked them over and think they're good, but given the +/- 1's > discussion on IRC, you may want to get further grooming

[Pulp-dev] Pulp 3 release quality

I've started putting together a Continuous Delivery of Pulp 3 page[0] on our wiki. This page outlines a plan for how we can ensure and prove the quality of Pulp 3 releases by relying on pulp-smash tests and unit tests. This plan enables anyone to improve the quality of Pulp 3 releases through

Re: [Pulp-dev] Importer Name

FWIW, I've looked them over and think they're good, but given the +/- 1's discussion on IRC, you may want to get further grooming consensus still. --Dana Dana Walker Associate Software Engineer Red Hat On Fri, Mar 23, 2018 at 1:51 PM, Austin

[Pulp-dev] Pulp 3 Unit Test Plan Proposal

We haven't had a unit test policy in Pulp 3, and the community and core committers would all like one. The general desire we've heard so far is to change course and encourage developers to add unit tests to their changes to Pulp 3. The policy we're suggesting is to add a coveralls[0] check for

Re: [Pulp-dev] Plugin relationship to tasks

To make sure this was feasable, I've created proof of concept PRs for pulpcore and pulp_file. All of the proposed changes are proofed, but not all work is done. For example, sync is implemented, but not publish. - https://github.com/pulp/pulp/pull/3394 -

Re: [Pulp-dev] Pulp 3 Unit Test Plan Proposal

-1 For a blocking check, -1 for attempting 100% coverage. There is a *lot* of code in Pulp 3 that simply involves inheriting from parents classes and defining attributes. If we add a ViewSet for instance, there is nothing to test other than "asserting that we did what we did". I have written lots