Umbrello, hybrid repository, Applications/17.08

Luigi Toscano luigi.toscano at tiscali.it
Sun Jul 16 22:44:46 UTC 2017


Luigi Toscano ha scritto:
> 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.

Forgot the link:
> 
> The maintainer turned on the KF5 version for non-Windows platform in
> Applications/17.08 today:

https://phabricator.kde.org/R139:71d1c6bdc961612535890428e0cf52c4107b24e9

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



More information about the release-team mailing list