<div dir="ltr">Sure, there’s a couple things we’re trying to accomplish. First is to deploy to PyPI which forces us to be OS agnostic. The whole Pulp 2 codebase is tied to Fedora/CentOS/RHEL when I don’t think it has to be. <div><br></div><div>The other goal is to make our build/testing processes simpler. Pulp 2 uses Jenkins AND Travis for things like testing PRs. Currently in Pulp 3, we’re just using Travis to test PRs. This offloads resources to Travis and means we don’t have to manage a CI environment.</div><div><br></div><div>Lastly, Jenkins is not accessible outside the Red Hat network. This is bad for upstream community as it means our testing of PRs and our build process is a blackbox.</div><div class="gmail_extra"><br clear="all"><div><div class="m_5069912082920362164m_-7576281002185188176gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Apr 24, 2018 at 8:22 AM, Bryan Kearney <span dir="ltr"><<a href="mailto:bkearney@redhat.com" target="_blank">bkearney@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_5069912082920362164m_-7576281002185188176HOEnZb"><div class="m_5069912082920362164m_-7576281002185188176h5">On 04/23/2018 02:57 PM, Patrick Creech wrote:<br>
> On Mon, 2018-04-23 at 14:01 -0400, Robin Chan wrote:<br>
>> I feel like the Travis change is recent enough that I'm not exactly sure how they differ from the Jenkins jobs. Are we all clear on these terminology? Aren't there multiple jobs running at different<br>
>> times? I am not comfortable enough without the assurance that we are all talking about the same things to say we don't need "the Jenkins jobs". I would like for some of these discussions around<br>
>> release process and where (and what and when)  different tests are run be a little bit more collaborative from the beginning rather than reactive post-change happening.<br>
>><br>
>> I'm all for making quick incremental changes. I'm happy that there are test results that are accessible to everyone. I don't want us to over thinking these, but are we sure we don't have any tests<br>
>> that need to stay private (do we test for any security type things that might need to be embargoed before reported)? I want to make sure we think thing through before we start tearing stuff down.<br>
>><br>
> The build team, for one, has not had time yet to do an assessment on if travis will be able to provide all the packaging related items needed to generate RPMs.  There are also infrastructure security<br>
> implications we have yet to analyze as well.  So, at least for rpm packaging requirements, these are still a big ? till we have time to evaluate.<br>
> <br>
<br>
<br>
</div></div>Can someone summarize for me what there is Yet Another Process?<br>
<span class="m_5069912082920362164m_-7576281002185188176HOEnZb"><font color="#888888"><br>
-- bk<br>
<br>
<br>
</font></span><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div></div>