[Development] QtWebKit is coming back (part 2)

[Oswald Buddenhagen]

On Wed, May 10, 2017 at 09:53:26AM +0200, Edward Welbourne wrote:
>    Oswald Buddenhagen (4 May 2017 18:35)
>    > i'll say outright that you can't be part of the qt supermodule and yet
>    > have independent releases. while that was the plan once upon a time, the
>    > whole release infrastructure simply doesn't deliver, and even just
>    > diverging branch names are a pita (proved by enginio).
> 
>    Can you elaborate on the pain here ?
> 
when the branch names are not uniform, they need to be derived from the
repositories' actual contents (.qmake.conf, in particular). and that has
historically been a mess because of lagging states due to late module
additions, tardy version updates, and delayed merges and qt5 integrations.

from the user perspective, diverging versions are a mess, because you
never know what belongs together. that was particularly annoying with
enginio, because there was no _reason_ for this being so.

>    I note, in particular, that we do have sub-sub-modules on branches
>    with eccentric names, or none 
>
these sub-modules' branches are completely desynchronized with qt, so
dealing with them is not part of the qt release cycle. qt simply pins
sha1s, and the modules are not directly in our CI.

>    What would we need to do to our release infrastructure to make it
>    cope with (as originally planned) independent release cycles for
>    distinct components ?
> 
i don't see how that would be logically possible at all as long as the
rest of qt is released as a monolithic product and at the same time some
qt modules depend on the prospective outliers. you would have to view
the outlier as an external dependency, but that doesn't work because it
depends on other qt modules, so it's circular.

for additional illustration, consider jira: due to the differing
versioning, you cannot use components for the outliers, but need
separate products.

as atomizing the release of most qt modules is totally unrealistic and
counterproductive, there isn't a way forward to arrive at a consistent
model which would accomodate that.

oh, and then there are the processes for creating an actual release.
have fun "forking" these for separate products ...