Umbrello, hybrid repository, Applications/17.08
Albert Astals Cid
aacid at kde.org
Wed Jul 19 21:36:10 UTC 2017
El dilluns, 17 de juliol de 2017, a les 0:11:00 CEST, Luigi Toscano va
> 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
> 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
> - 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).
To be honest i don't care if master is kdelibs4 or Qt5 based, but the hybrid
branch has to stop.
One of the points of the KDE Manifesto that says "The project stays true to
established practices common to similar KDE projects" and Umbrello has been
creating us pain for a long time by not using the established common
So just get the master and Applications/17.08 branch to be like they should be
(just based in one of Qt4/Qt5). If the Umbrello developers want to have extra
branches where they have hybrid code, it's a burden they can have, but putting
the burden on the rest of KDE has to stop.
> 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.
More information about the release-team