Control: tag -1 moreinfo Hi Luca,
On Mon, Dec 18, 2017 at 14:46:04 +0000, Luca Boccassi wrote: > DPDK maintains LTS branches upstream for 2 years [1]. This is covered > by regressions tests from Intel and AT&T on various networking hardware > and virtualized environments.These tests are run to validate the > release branch before tagging a new version. Other hardware vendors > regularly test these LTS versions too. They are also used by other > distros such as RedHat and Ubuntu. > Only bug fixes that affect that release branch, and that have already > been merged in the mainline, are allowed. No API/ABI changes of any > kind are allowed. Full changelog can be found at the bottom of the > release notes [2]. > Each major mainline release is followed by an LTS branch release, where > the relevant bug fixes are backported, so there are usually 4 bugfix > LTS releases per year. There are usually between 10 and 100 patches > backported per release. > > Stretch shipped with the first release of 16.11. Since then, there have > been 4 bugfix LTS releases, up to 16.11.4 a few days ago. > We have uploaded them to unstable/testing/stretch-backports. > > We would like to take advantage of the upstream LTS maintenance and > push these point releases to Stretch. > > Attached is the full debdiff. I can provide a debdiff for each > individual point release between 16.11 and 16.11.4 if required. > There is only one change in dependency, python-elftools was demoted > from Recommends to Suggests as it's not useful in most cases. I think > this change is fine but can remove it if asked. > > Patches to fix bugs reported on Ubuntu, and to make the build > reproducible, are also included. I can remove them if asked. > > The changelog is inlined at the bottom. > > Although the main users are Debian users with custom software, there is > a reverse build-dep in Stretch as well, collectd. It works fine with > the new LTS version. > Thanks for the detailed explanation, that helps. A few comments: - I'd rather do without the changes in debian/control - likewise init script, pkg-config file (unless there's an explanation) - the above doesn't seem to address the changes in debian/patches/, can you detail the reason behind each of those? - I think from our perspective the reproducibility changes are adding more risk than anything else, and normally not appropriate for stable - the change in prep-modules, generating dependencies on the exact version of linux-image rather than the ABI (probably with ">=" the build version), looks wrong. I don't know if/how that is used by the package though. - the debian/rules changes introduce noise, so if that can be trimmed down it would be welcome - I can't speak to the upstream changes, but no objection in principle if that stuff is tested as you describe. Is any of the LTS branch testing done in a Debian stable environment, either by upstream, you, or some other users of this code? Cheers, Julien
