12.04.2017 20:25, Niels Thykier wrote: [] >>> Just to be sure, are you recommending 1:2.8+dfsg-4 or that we go with >>> upstream's 2.8.1 release? >> >> Historically, for some reason I don't remember what, we >> kept the "major" upstream version and source in qemu and >> used just a patch (v2.8.1.patch in this case) pulled from >> upstream (tarball or git difference, which is the same in >> this case).
> I don't remember that reason either and no one was able to remind me. :) > > Could I convince you to do a debdiff of the upstream release as an > actual new upstream release (and not just stuff into a big patch wrapped > up with fake version number)? :) I'm not sure what's the reason to update the tarball. Maybe that actually was a reason to do it this way really, -- the changes are small compared with the size of the tarball, and DFSG-ification of it is rather complex. At the same time we already have big number of patches from current upstream stable release, so the version number is better be like this, as it is "based" on 2.8. If there's no strong reason, I'd rather not change or touch the release procedure this late in the release cycle, I did a number of mistakes in DFSG-ification already in the past. I can split the upstream v2.8.1 patch into individual patches if that'll help. This way there won't be much moving in the debdiff (there will be the same amount of patch moving if I'll base it on actual 2.8.1 tarball). Or, provided there's already 2.9 upstream release coming out, just give up on stretch version and focus on backports instead, the same way as we did in jessie (I weren't able to convince the release team to accept a single bugfix release from upstream). Unfortunately upstream does not keep stable series alive, so there wont be any further updates for 2.8 series. Thanks, /mjt
