Hi everyone! I would like to discuss the current situation for Qt4's Webkit in 

Let me first start with some facts:

= Facts =

- Both Qt4 and (by inclusion) Qt4's webkit are no longer supported upstream.

- If a security bug appears in Qt4 during Stretch's lifetime I'm pretty sure 
we will be able to come up with a patch. There is too much people depending on 
it out there so this won't be a problem for Stretch.

- For Qt4's webkit the situation might probably be the other way around. 
Actually we might already have (quite some?) security bugs out there.

= Removal efforts and options =

So last year we started to work on removing it [removal]. Progress is sadly 
far from good. We still have quite a lot of apps depending on qebkit in order 
to show things like doc. Most of them do not use it for web browsing.

[removal] <https://wiki.debian.org/Qt4WebKitRemoval>

This has been discussed in the Qt/KDE team quite a lot of times with different 
opinions. For what I could gather the possible options are:

(keep) Keep Qt4's webkit as it is in Stretch and warn users that they will get 
*no* security support.

(removeintesting) Remove Qt4's webkit from testing, file an RC bug against it 
so it doesn't transition and let rdeps be removed from testing until they 
switch. Of course we will need the RT's approval for this.

(totalremove) Remove Qt4's webkit from the archive together with it's rdeps 
(or leave the rdeps RC buggy in unstable).

Does anyone has a better idea?

= What do we do? =

If we take the (keep) option we need a good way to ensure users get the fact.

If we go for any of the other two options we will need the RT/FTP team to ACK 
the move.

So I would really like to hear the opinions of people in both teams. If you 
really think a certain way forward should be taken please speak now.

Kinds regards, Lisandro.

Lisandro Damián Nicanor Pérez Meyer

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply via email to