[webkit-gtk] Policy for versions of deps used in internal jhbuild for testing

[Carlos Garcia Campos]

We have recently set a policy for the minimum version required to build
WebKitGTK+. I would like to set a policy also for the versions used
internally in the jhbuild using for testing.

The currently non-written rule is that when we notice that a new
version of a dependency fixes a bug or a test, we bump the required
version, otherwise we keep the same versions. This conservative
approach is very convenient because we don't need to do major
rebaselines very often, but it has several disadvantages:

 - When a new version of a dependency introduces a bug, the bots don't
notice it, but users do. This has happened several times with GStreamer
for example.

 - Newer code that depends on newer version of a dependency, is not
tested at all.

 - Our tests are far from what users actually use, we should ensure
that what we test is closer to what most users will find.

 - Some people use the internal jhbuild also to build WebKitGTK+ and
other applications depending on it, like Epiphany. That's not
recommended at all, the internal jhbuild is only useful to "ensure"
same layout tests results, but it doesn't make sense to use Epiphany
with moder WebKitGTk+ linking with old versions of GTK+, GLib, Cairo,
etc.

So, for all these reasons I think we should use the latest stable
version of all our dependencies. It's still possible that we can break
something for an older version of a dependency and bots won't notice
it, but that won't affect most of the users, so better catch erros with
the modern versions.

My proposal is to update the dependencies all together once every
release cycle, to avoid having to rebaseline several times, and then
following our current approach, bumping a version only when required to
fix a test. The update could be at the beginning of the cycle, before
making the first unstable release, but right after the second stable,
so that we will use .1 version of our deps following the GNOME
schedule.

But for this to work we need to reduce the amount of failing tests in
the bots, otherwise rebaselines are going to be a nightmare. So,
Michael proposed to try to do an extra gardening effort for a month, to
drastically reduce the failures, ideally making the bots green, and
then do the first upgrade.

Opinions?
 
-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20161004/dbf3c412/attachment.sig>