On Thu, May 31, 2018 at 12:26 PM, Luca Boccassi <bl...@debian.org> wrote:
> Hello all, > > At this morning's release meeting (minutes coming soon from John), we > briefly discussed the state of the regression testing for stable > releases and agreed we need to formalise the process. > > At the moment we have a firm commitment from Intel and Mellanox to test > all stable branches (and if I heard correctly from NXP as well? Please > confirm!). AT&T committed to run regressions on the 16.11 branch. > > Here's what we need in order to improve the quality of the stable > releases process: > > 1) More commitments to help from other companies involved in the DPDK > community. At the cost of re-stating the obvious, improving the quality > of stable releases is for everyone's benefit, as a lot of customers and > projects rely on the stable or LTS releases for their production > environments. > > 2) A formalised deadline - the current proposal is 10 days from the > "xx.yy patches review and test" email, which was just sent for 16.11. > For the involved companies, please let us know if 10 days is enough. In > terms of scheduling, this period will always start within a week from > the mainline final release. Again, the signal is the "xx.yy patches > review and test" appearing in the inbox, which will detail the > deadline. > > Hi Luca, I discussed with Thomas about it. I don't know how much extra effort for the stable maintainers it would be, but I wonder if there could be a XX.YY.z-rc tarball. That would be a) a more clear sign what people are used to test b) easier to integrate as I assume quite a bunch of tests will usually start rebasing on tarballs instead of directly from git. If you think everyone can derive from git easily I'm fine, I just wondered if a proper -rc tarball might be more comfortable for the testing entities. cu Christian
