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.


- 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.


Reply via email to