<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/111042/">http://git.reviewboard.kde.org/r/111042/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On June 15th, 2013, 7:06 p.m. CEST, <b>Albert Astals Cid</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Is this some kind of joke?
Honestly upstreaming patches is good, but when they make sense, and adding billions of "If #SUSE" to our code does not make any sense. Please discard this review, break stuff in separate patches and if they make sense we can discuss adding them upstream without the "IF SUSE".</pre>
</blockquote>
<p>On June 15th, 2013, 11:02 p.m. CEST, <b>Johannes Obermayr</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Do you remember on http://tsdgeos.blogspot.de/2010/05/complex-systems-are-complex.html and how long I had to study openSUSE's kdelibs4 package which of the patches were applied and which not, rebuilding packages, installing -debuginfo, etc.? Last sentence is one of the reasons for my wish to get also distro specific patches upstream - not only openSUSE's.
If I remember right there were and should be some distro specific bug reports on bko: The more people have easy access to source code in "Complex systems [which] are complex" the likelier reasons for specific bugs can be tracked down ...
Yes, binding upstream developers to downstream changes/problems is not really nice but could also mean a win-win-situation for both: downstream devs will do more upstream work and upstream devs can review downstream work, better find distro specific bugs and assign them to downstream devs.
Intention of this review request is to start a discussion ...</pre>
</blockquote>
<p>On June 16th, 2013, 9:07 a.m. CEST, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Upstreaming the patches with if #SUSE doesn't solve the problem: one still doesn't know which code is run by a user's setup. Even worse: the chances for bitrot increase. The current system of downstream patches mean that the distribution has to ensure that the patches apply on new versions. A human has to look at each of them. That's the cost of having downstream patches. If you currently not do that (e.g. debug areas for non shipped software) you should rethink whether you have too many patches.
For downstream patches there are the following possible solutions:
* Try to upstream them: if upstream accepts them you get rid of the patch, if upstream doesn't accept you should best drop the patch, too
* For distro-specific behavior: add abstraction with plugin system and upstream
* keep patches for build issues (common example: compile errors with non C++ compliant compilers)
Personally I would go so far that we as upstream say that we don't accept bug reports in case the distributions carries downstream patches.</pre>
</blockquote>
<p>On June 16th, 2013, 8:07 p.m. CEST, <b>Luca Beltrame</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">[Johannes]
> Intention of this review request is to start a discussion ...
Use the mailing list, not a review request, to start a discussion (and do not upload a broken patch).
> how long I had to study openSUSE's kdelibs4 package which of the patches
Then you should have contacted the openSUSE community KDE team first, since we had already started a patch review of the distro-shipped patches. I reiterate that the rest of the team is absolutely against this RR. And you should have noticed by now that we strive already to push things upstream.
[Martin]
> * Try to upstream them: if upstream accepts them you get rid of the patch, if upstream doesn't accept you should best drop the patch, too
For some case, it is not possible as desirable functionality will not be integrated upstream in some cases (e.g. KDM with plymouth, to make an example). </pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">@Martin:
> Upstreaming the patches with if #SUSE doesn't solve the problem: one still doesn't know which code is run by a user's setup.
I don't understand this. If an user tells (s)he uses openSUSE's RPM which are compiled with code within "#if defined(DISTRO_SUSE) ... #endif" you should be able to say which code is running.
> Even worse: the chances for bitrot increase. [...] * For distro-specific behavior: add abstraction with plugin system and upstream
Can't bitrot increase also happen on an abstraction layer?
I think the preprocessor solution is the better one because it results in faster and smaller binaries without binding other distributions to code they don't use:
if (access ("/etc/SuSE-release", R_OK) != 0) {
openSUSE_specific_code
}
takes more CPU cycles in binary than
Add -DDISTRO_SUSE=1 to FLAGS
#if defined(DISTRO_SUSE)
openSUSE_specific_code
#endif
Also this patch could be upstreamed only with preprocessor solution:
https://build.opensuse.org/package/view_file?expand=1&file=add-suse-translations.diff&package=kdelibs4&project=KDE:Distro:Factory
> Personally I would go so far that we as upstream say that we don't accept bug reports in case the distributions carries downstream patches.
So sb. must adapt drkonqi to deny sending bug reports from openSUSE RPMs to bko.
@Luca:
> - ksuseinstall is actually on its way to be *killed* in future openSUSE versions.
> - Stuff like YMP handlers (one-click installs)
> - The patch is *broken* in many ways, including adding debug areas for non shipped software (kupdateapplet), a lot of needless compatibility layers (KDE3) etc. It's just a wholesale port made without any serious efforts at reviewing.
Why don't you drop obsolete patches and waste binaries then?
[Off-topic] Grumble and then don't change anything (e. g. kdebug-areas-update.diff is still applied in KDF - it takes <30 seconds to remove it). That's my long experience with elitist openSUSE KDE maintainers who cannot accept new maintainers for KDE: projects because of missing rules for that [1] (or maybe my accepted requests [2] were insufficient and nobody wants to say this).[/Off-topic]
>> Intention of this review request is to start a discussion ...
> Use the mailing list, not a review request, to start a discussion (and do not upload a broken patch).
This way the [final] code can be easily reviewed and commented. I will upload a patch series and close this review request if a solutions is found ...
[1] https://bugzilla.novell.com/show_bug.cgi?id=706813#c16
[2] https://build.opensuse.org/home/requests?user=jobermayr (please change to "accepted")</pre>
<br />
<p>- Johannes</p>
<br />
<p>On June 15th, 2013, 6:27 p.m. CEST, Johannes Obermayr wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for kdelibs.</div>
<div>By Johannes Obermayr.</div>
<p style="color: grey;"><i>Updated June 15, 2013, 6:27 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Distributions should upstream their patches / changes:
- Upstream / other distributions can easily see distro specific changes and enable them by default by removing "#if defined(DISTRO_xxx)"
- Maybe duplicate work can be avoided and other distributions can easily use them by "|| defined(DISTRO_xxx)"
- Less adaptions of downstream patches ...</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>CMakeLists.txt <span style="color: grey">(705c84e)</span></li>
<li>kdecore/config/kconfig.cpp <span style="color: grey">(048605d)</span></li>
<li>kdecore/config/kconfig_p.h <span style="color: grey">(7751242)</span></li>
<li>kdecore/config/kconfigdata.h <span style="color: grey">(e5dd7da)</span></li>
<li>kdecore/config/kconfiggroup.h <span style="color: grey">(8eddfd5)</span></li>
<li>kdecore/config/kconfiggroup.cpp <span style="color: grey">(9e73eb7)</span></li>
<li>kdecore/config/kdesktopfile.h <span style="color: grey">(1c4eae6)</span></li>
<li>kdecore/config/kdesktopfile.cpp <span style="color: grey">(54e5910)</span></li>
<li>kdecore/kdebug.areas <span style="color: grey">(29a4415)</span></li>
<li>kdecore/localization/klocale_kde.cpp <span style="color: grey">(b010e74)</span></li>
<li>kdecore/services/kservice.h <span style="color: grey">(3843bad)</span></li>
<li>kdecore/services/kservice.cpp <span style="color: grey">(e2cc86f)</span></li>
<li>kdecore/services/kservicegroup.h <span style="color: grey">(9fdf2b0)</span></li>
<li>kdecore/services/kservicegroup.cpp <span style="color: grey">(08bc587)</span></li>
<li>kdecore/services/kservicegroup_p.h <span style="color: grey">(5f21497)</span></li>
<li>kded/vfolder_menu.cpp <span style="color: grey">(f0b0b35)</span></li>
<li>kdesu/defaults.h <span style="color: grey">(706a088)</span></li>
<li>kdeui/kernel/kglobalsettings.cpp <span style="color: grey">(2e3a7eb)</span></li>
<li>khtml/html/html_objectimpl.cpp <span style="color: grey">(f0f590d)</span></li>
<li>kio/CMakeLists.txt <span style="color: grey">(4854829)</span></li>
<li>kio/kio/kprotocolmanager.cpp <span style="color: grey">(05bb547)</span></li>
<li>kio/kio/krun.cpp <span style="color: grey">(ad5656e)</span></li>
<li>kjs/collector.cpp <span style="color: grey">(cdd8421)</span></li>
<li>plasma/containment.h <span style="color: grey">(e725a99)</span></li>
<li>plasma/containment.cpp <span style="color: grey">(fc2ca70)</span></li>
<li>plasma/private/containment_p.h <span style="color: grey">(75a6f80)</span></li>
<li>plasma/theme.cpp <span style="color: grey">(4554de7)</span></li>
<li>suseinstall/CMakeLists.txt <span style="color: grey">(PRE-CREATION)</span></li>
<li>suseinstall/kbuildsycocaprogressdialog.h <span style="color: grey">(PRE-CREATION)</span></li>
<li>suseinstall/kbuildsycocaprogressdialog.cpp <span style="color: grey">(PRE-CREATION)</span></li>
<li>suseinstall/ksuseinstall.h <span style="color: grey">(PRE-CREATION)</span></li>
<li>suseinstall/ksuseinstall.cpp <span style="color: grey">(PRE-CREATION)</span></li>
<li>suseinstall/ksuseinstall_export.h <span style="color: grey">(PRE-CREATION)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/111042/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>