From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============7782137644329211171==" MIME-Version: 1.0 From: Lance Hartmann ORACLE Subject: [SPDK] Add Jenkins job for periodic (nightly?) test run against upstream DPDK stable? Date: Mon, 11 Feb 2019 17:43:55 -0600 Message-ID: List-ID: To: spdk@lists.01.org --===============7782137644329211171== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Group, I recently had a sideband chat with Jim regarding our SPDK testing with the= DPDK, and he urged I open this up to the email list for more discussion. When a Linux distro produces SPDK package rpms, they satisfy the DPDK depen= dency via a specified stable DPDK release from upstream that has been packa= ged. However, on the run up to each SPDK quarterly release, we are consta= ntly building and testing against the SPDK's fork'd copy of the DPDK (as a = git-submodule) on which we often (virtually always?) have our own patches. = While this works fine for a development perspective as we work toward the= next SPDK release, it's problematic when the time arrives to produce new S= PDK packages because they will be built against a pristine DPDK stable rele= ase which very likely is not identical with what we have been testing again= st. When I described this with Jim, he agreed that it would be an excelle= nt idea to augment our SPDK Jenkins setup with some tests which would run a= gainst the latest "pristine" (i.e. upstream stable) DPDK release. With th= at in place, when the time arrives to produce new SPDK packages, we will ha= ve gained the testing confidence of having validated running with the exact= version of the DPDK against which the SPDK packages will have been built (= and will run alongside at runtime). Having said all that, I did float another idea on how we could, if we reall= y needed to, produce SPDK package rpms based on the combination of a stable= DPDK upstream release and our own collection of patches to it. The rpm p= ackaging system natively supports such a build, but as you might quickly de= duce it comes at the cost of additional maintenance efforts which can becom= e very unpalatable, esp. when/if some of our patches are never accepted/mer= ged into the official upstream DPDK tree. -- Lance Hartmann --===============7782137644329211171==--