Umbrello, hybrid repository, Applications/17.08

Nicolás Alvarez nicolas.alvarez at gmail.com
Tue Jul 18 02:47:38 UTC 2017


2017-07-16 21:14 GMT-03:00 Jack Ostroff <ostroffjh at aya.yale.edu>:
> On 2017.07.16 18:11, Luigi Toscano wrote:
>>
>> Hi all,
>>
>> umbrello follows an hybrid structure (both Qt4 and Qt5 version at the same
>> time, with a lot of if-defs) which poses some complications to our
>> infrastructure.
>>
>> The maintainer turned on the KF5 version for non-Windows platform in
>> Applications/17.08 today:
>>
>> You can read my comments, but in a nutshell:
>> - the English documentation use a trick (the cmake equivalent of sed) to
>> use
>> the native DTD of Frameworks documentation;
>> - the translated DTDs can't do the same. So they will rely on the DTD of
>> the
>> original
>> - when the translated documentation are injected back, as it happens now
>> for
>> KF5 applications, they will introduce an implicit dependency on
>> KDELibs4Support, which is not defined.
>>
>> I tried to explain the issue with the documentation in the past but with
>> no
>> success. There is also a similar issue related to the usage of a piece of
>> documentation on its own inside the program.
>>
>> The stated reason for keeping this hybrid model is the support of Windows.
>> Now, I think that it's possible to keep this:
>> - keep a "kdelibs4" branch for Windows, commit there the bugfixes
>> - upmerge into "master" (or "Applications/xy.zt"), which would be pure
>> Qt5.
>>
>> I would like to ask to revert the change and keep umbrello officially
>> kdelibs4, and work to move to pure Qt5 before Applications 17.12 (aka
>> fixing
>> the issues on Windows).
>>
>> Otherwise I will have to workaround this in the release scripts in various
>> ways:
>> - not injecting the localized documentation (at least visible on the
>> website)
>> - adding an extra dependency to kdelibs4support in the umbrello cmake code
>> - fixing the DTD while injecting the localized documentation (definitely
>> hard)
>>
>> The last one would be a special rule just for one program, which takes
>> time
>> for no reasons and add a maintenance cost. I personally don't like how the
>> common rule and expectation has not been followed for this repository,
>> which
>> introduces difficulties for the rest of the community.
>>
>> Ciao
>> --
>> Luigi
>
> Luigi,
>
> I have not used KDE/Windows in quite a while, but are they not capable of
> handling Frameworks and Qt5 based builds?  I do not have my Windows box
> handy to actually check myself.
>
> Jack

In my experience, on Windows it's *easier* to deal with Qt5/KF5 than
with the monolithic kdelibs4.

-- 
Nicolás


More information about the release-team mailing list