On Sat, Jun 29, 2019 at 12:03:05PM +0200, Alberto Garcia wrote: > > @Alberto, did you have any intention to upload to backports once > > buster is released? If so, do you think it is OK to mention this > > in the release-notes? > > Yes, my plan is to publish backports of every stable WebKitGTK > release. I have been doing it for stretch without problems for the > last couple of years.
I'll elaborate a bit more: - The next upload that goes to buster (either via backports or any other means) will support non-SSE2 CPUs. It's most likely going to be a backport of 2.24.2-2. - WebKitGTK upstream has a dependency policy according to which the package is supported in Debian stable until one year after the release of the next major version. So stretch is supported until summer 2020 and buster until one year after bullseye. https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy - When upstream publishes a new version I upload it to unstable typically on the same day, and to stable-backports as soon as the package hits testing. stretch-backports has always had an up-to-date version of webkit2gtk, and I plan to do the same for buster-backports (and for stretch-backports as long as it works). - In addition to that we are also having buster-security updates of webkit2gtk for the first time. However we are not cherry-picking security fixes, we will be using the latest upstream stable release (the same that goes to buster-backports, actually). My plan is to delay the security updates for some days in order to have time to test them and detect regressions. One may argue that it's a bit pointless to have the same upstream releases going to buster-backports and buster-security, but the former will also receive updates that don't contain security fixes and will generally be less conservative with the timings. Berto