[Pulp-dev] Pulp 3 Release Process Questions

[Brian Bouterse]

On Mon, Apr 23, 2018 at 4:33 PM, Patrick Creech <pcreech at redhat.com> wrote:

> On Mon, 2018-04-23 at 15:22 -0400, Brian Bouterse wrote:
> > 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.
> >
> > 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
> > 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.
> >
>
> 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
> 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.
>

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.


>
> 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
> that is a great attitude to have with regards to pulp's userbase.
>

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.


>
> 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
> specifically on said distributions. (i.e. selinux, systemd daemon scripts,
> etc...).
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180423/c9c16d9f/attachment.htm>