[Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

11.05.2017, 16:10, "Oswald Buddenhagen" <oswald.buddenhagen at qt.io>:
> 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.

I would be possible to pin sha1 in qt5.git from the tip of current stable branch
of the module, in the same manner as it's done now (except branch name
will be different and may be upgraded between Qt's patch releases)

As long as superbuild works, I don't see any technical problem with the
"circular" dependency.

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

That's true.

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

Why?

For example, GNOME has a platform consisting of lots of libraries with
independent versioning and release schedules, and it works because
these libraries provide certain API/ABI guarantees

>
> oh, and then there are the processes for creating an actual release.
> have fun "forking" these for separate products ...
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin