<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 23, 2018 at 4:33 PM, Patrick Creech <span dir="ltr"><<a href="mailto:pcreech@redhat.com" target="_blank">pcreech@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 2018-04-23 at 15:22 -0400, Brian Bouterse wrote:<br>
> Travis CI runs a few OSes, but not RHEL and Fedora, or many others. Travis is good for ensuring that Pulp's main release asset (the pypi packages) are being tested continuously.<br>
> <br>
> Ensuring that Pulp runs on any given OS is a different kind of testing. Whoever packages for a given distro (rhel, fedora, debian, etc) will need to determine how they will test/track the<br>
> correctness of the packaged asset itself. To that end the build team may want to run pulp smash against built RPMs in a different environment other than Travis and that would be fine.<br>
> <br>
<br>
</span>One thing to point out here, there is a difference in ensuring that pulp installed from pypi runs on various distributions, and ensuring that distribution specific packages run on successfully on<br>
their respective distributions.  The extent of whatever testing is done on rpms would/should be done in a way that ensures the rpm packaged version works the same as the pypi packaged version.<br></blockquote><div><br>I agree, the pypi asset is quality checked with smash and unit tests, and any packaged assets (deb, msi, containers, etc) should also be. The unit and smash tests are available so that at packaging time quality can be ensured. Whoever does the packaging needs to determine how/where they want to run them.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Pulp 2's userbase primarily uses rpm based distributions.  If your support statement is 'It works on travis!' without ensuring pulp 3 works on your dominant userbase's machines, then I do not think<br>
that is a great attitude to have with regards to pulp's userbase.<br></blockquote><div> </div><div>I don't think our claim has to do with Travis. The quality claim for pypi is the same approach as with Pulp2: "we ran X unit tests and Y smash tests and there were 0 errors so we released". Users can understand what our quality claim is by reading the functional tests. These quality checks will be run at pypi release time, and I think doing it at rpm release time would be consistent. Running the unit and smash tests at packaging time on a given distro will provide that consistent quality claim in the packaged assets. Untested assets I think come with no guarantees to their users.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And while build team is happy to provide automation, configuration, and setup to help package up pypi packages into rpms, I doubt we can commit to doing the legwork to ensure the code itself works<br>
specifically on said distributions. (i.e. selinux, systemd daemon scripts, etc...).<br></blockquote><div><br>I think we're on the same page here.  The systemd scripts are provided in the docs by the devs. SElinux is 
it's own special thing, for now the plan is to ship pypi with selinux disabled so rpms could do that too. I don't expect the build team to produce an SELinux policy.<br></div><div> <br></div></div><br></div></div>