Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On 06/07/2011 01:41 PM, Thiago Macieira wrote: On Tuesday, 7 de June de 2011 10:14:43 Alexander Neundorf wrote: On Tuesday, June 07, 2011 08:21:02 AM Sebastian Trüg wrote: Just as a side-note on SDO: For me SDO is very close to the KDE development process. If I had my way everyone running KDE master would also use SDO master. But for some reason that would only be acceptable if SDO were in KDE's git... It could be integrated into a virtual kdesupport, independent from where it is hosted. doesn't kdesrc-build actually do this ? The part shared-desktop of the name seems to imply that it's not that close to the KDE development process. If they are so close to the KDE development process, why aren't they called kde ontologies instead? SDO is intended to be shared between desktop frameworks and was actually started as a shared project between KDE and Ghome. Sadly Tracker uses their own fork of it and does not contribute the changes back (although they have claimed to be planning to do it for a long time). Renaming it would be a IMHO bad move now. It being close to the KDE development process simply stems from the fact that I maintain it and add features when I need them for KDE. So the reasons are simply of a practical nature. Cheers, Sebastian Otherwise, it looks like people from the other camp who name their technologies under generic names like Notifications or libwebkit and pretend that they are the official solution for everyone.
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
Just as a side-note on SDO: For me SDO is very close to the KDE development process. If I had my way everyone running KDE master would also use SDO master. But for some reason that would only be acceptable if SDO were in KDE's git... On 06/06/2011 06:53 PM, Thiago Macieira wrote: On Monday, 6 de June de 2011 17:48:41 Martin Gräßlin wrote: Personal opinion: I think it is impossible to want to run the latest software around an old stack. The overall FOSS world is rolling release with everything depending on everything. I cannot see why you want to change that with a moratorium. I agree on that, but I disagree on the age of the old stack. For example, I'm running the Mandriva rolling-release right now and I can't compile kdepim and kdepimlibs because they haven't packaged yet shared-desktop-ontologies 0.7. That was released less than one month ago. I'd say that hard dependencies need to be at least a couple of months old, unless there's a very good reason for doing otherwise. And in that case, it should be announced in advance so that distributions and users can prepare themselves. * Shared desktop ontologies (0.6.51 or higher) http://oscaf.sourceforge.net Desktop ontologies Ontologies necessary for the Nepomuk semantic desktop. Download date: http://sourceforge.net/projects/oscaf/files/shared-desktop-ontologies/0.7/
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On 06/06/2011 10:51 PM, Ben Cooksley wrote: On Tue, Jun 7, 2011 at 8:42 AM, Martin Gräßlin mgraess...@kde.org wrote: On Tuesday 07 June 2011 08:29:51 Ben Cooksley wrote: Next KWin. It currently depends upon Mesa 7.10. I have a local revert in a private local branch which reverts the dependency check code within KWin to continue to allow me to use compositing. Even though I have Mesa 7.8, I rarely experience KWin crashes - it has only crashed once in the past 2 months. I use an Intel Ironlake based graphics. This patch of mine works perfectly and does not cause any issues. KWin does *not* depend on Mesa 7.10! KWin does not have any build dependencies on Mesa. There is an optional build dependency on OpenGL and XComposite/XDamage. This all is optional! If you use Mesa drivers there is a runtime requirement for at least Mesa 7.10, whose reasons have been explained to you on plasma-devel. Given what you demand this is out of scope as it is not a build dependency. It is just that you don't get the latest features when not having the correct runtime dependency. I might add that using different drivers (NVIDIA or ATI blob as well as GLES/EGL Mesa drivers) do not have this runtime requirement. It is also still possible to use KWin with XRender or without compositing at all. Btw. patches to have an environment variable to overwrite all checks are welcome. Please also note that I will add a runtime requirement to Mesa 7.11 as I have here on my system the start of the Wayland port which will be in 4.8 and requires Mesa 7.11. Now that is absolutely overboard. OpenSUSE 11.4 isn't even 3 months old. And has Mesa 7.10. You are effectively classifying a distribution as unsuitable for trunk development. You are now depending on components which aren't even in released distributions! (Note that having to live with a desktop without compositing isn't exactly what I would call usable for the long run) IMHO it is out of the question to ask a developer to not implement a great new feature just because the dependancies are too young. In that case you should just stick with an older version of KDE itself. Whom who wants the bleeding edge of KDE might also need the bleeding edge of all the rest (in the worst case). Restricting ourselves will lead to branching and a lot of wasted time on ifdefs and cmake checks. This wasted time could otherwise be used to create great new features and fix bugs. Isn't this the way open-source software is supposed to work? Collaborate, depend on the work of others? Restricting ourselves to old versions (and as a developer anything released is old for me) means to restrict the power we have and undermines our very development model. Cheers, Sebastian Cheers Martin Regards, Ben
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On Tuesday 07 June 2011 Jun, Sebastian Trüg wrote: Restricting ourselves to old versions (and as a developer anything released is old for me) means to restrict the power we have and undermines our very development model. In my opinion, almost always needing the development version of e.g. GTK is what is keeping GIMP a project with hardly any contributors. But that's an application, not a framework. Still -- if you want to have a healthy project with many contributors, making it hard to develop by requiring lots of unpackaged isn't a good idea. -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
- Original Message - IMHO it is out of the question to ask a developer to not implement a great new feature just because the dependancies are too young. I disagree completely. I would very much welcome a policy that states that you can only depend on stuff that is available in the newest release of Fedora KUbuntu other KDE friendly distro's. Toma
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On Tuesday, 7 de June de 2011 07:53:28 Tom Albers wrote: - Original Message - IMHO it is out of the question to ask a developer to not implement a great new feature just because the dependancies are too young. I disagree completely. I would very much welcome a policy that states that you can only depend on stuff that is available in the newest release of Fedora KUbuntu other KDE friendly distro's. Note that both options are possible. You can use newer versions if they are available and thus develop using features found in those newer versions. You just have to make sure it still compiles with older (packaged) versions. The minimum requirement should be a released version at least a couple of months old. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On Tuesday, June 07, 2011 09:32:09 AM Boudewijn Rempt wrote: On Tuesday 07 June 2011 Jun, Sebastian Trüg wrote: Restricting ourselves to old versions (and as a developer anything released is old for me) means to restrict the power we have and undermines our very development model. In my opinion, almost always needing the development version of e.g. GTK is what is keeping GIMP a project with hardly any contributors. But that's an application, not a framework. Still -- if you want to have a healthy project with many contributors, making it hard to develop by requiring lots of unpackaged isn't a good idea. I fully agree. Alex
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On Tuesday, 7 de June de 2011 10:14:43 Alexander Neundorf wrote: On Tuesday, June 07, 2011 08:21:02 AM Sebastian Trüg wrote: Just as a side-note on SDO: For me SDO is very close to the KDE development process. If I had my way everyone running KDE master would also use SDO master. But for some reason that would only be acceptable if SDO were in KDE's git... It could be integrated into a virtual kdesupport, independent from where it is hosted. doesn't kdesrc-build actually do this ? The part shared-desktop of the name seems to imply that it's not that close to the KDE development process. If they are so close to the KDE development process, why aren't they called kde ontologies instead? Otherwise, it looks like people from the other camp who name their technologies under generic names like Notifications or libwebkit and pretend that they are the official solution for everyone. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Requested Moratorium on hard to build dependency bumps for KDE 5
Hi all, I am requesting that a moratorium on dependency bumps for dependencies which are hard to build be enacted. This would affect system wide components which rely on root access and are heavily integrated into the system. This would not affect things such as UPower or the like - which aren't heavily integrated - but only heavily integrated things such as the kernel, X and ALSA. Over the past few months it has become increasingly hard to use a distribution which isn't even 1 year old to build KDE trunk. Custom patches, disabled features and compilation failures are fairly common, and represent an extreme barrier to contribution. This would only affect releases after KDE 4.7. Regards, Ben
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On Monday 06 June 2011 23:05:52 Ben Cooksley wrote: Hi all, I am requesting that a moratorium on dependency bumps for dependencies which are hard to build be enacted. This would affect system wide components which rely on root access and are heavily integrated into the system. This would not affect things such as UPower or the like - which aren't heavily integrated - but only heavily integrated things such as the kernel, X and ALSA. For what modules do you want such a moratorium? Given that you mailed core-devel I assume the Plattform. There I am very sure that we do not need to expect an X12 before KDE 4.8 is released ;-) But given that you mention X I rather think you want to have a moratorium for the Workspaces. In that case please take the request to Plasma devel so that we can discuss raised requirements on a per-component base. A general moratorium just looks like a wonderful way to do bike-shedding. Over the past few months it has become increasingly hard to use a distribution which isn't even 1 year old to build KDE trunk. Custom patches, disabled features and compilation failures are fairly common, and represent an extreme barrier to contribution. This would only affect releases after KDE 4.7. Personal opinion: I think it is impossible to want to run the latest software around an old stack. The overall FOSS world is rolling release with everything depending on everything. I cannot see why you want to change that with a moratorium. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On Monday, 6 de June de 2011 17:48:41 Martin Gräßlin wrote: Personal opinion: I think it is impossible to want to run the latest software around an old stack. The overall FOSS world is rolling release with everything depending on everything. I cannot see why you want to change that with a moratorium. I agree on that, but I disagree on the age of the old stack. For example, I'm running the Mandriva rolling-release right now and I can't compile kdepim and kdepimlibs because they haven't packaged yet shared-desktop-ontologies 0.7. That was released less than one month ago. I'd say that hard dependencies need to be at least a couple of months old, unless there's a very good reason for doing otherwise. And in that case, it should be announced in advance so that distributions and users can prepare themselves. * Shared desktop ontologies (0.6.51 or higher) http://oscaf.sourceforge.net Desktop ontologies Ontologies necessary for the Nepomuk semantic desktop. Download date: http://sourceforge.net/projects/oscaf/files/shared-desktop-ontologies/0.7/ -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On Tuesday, June 7, 2011 06:19:52 Ben Cooksley wrote: The Moratorium would extend to all components of the KDE SC distribution. Hence kde-core-devel. imho this is impossible, for the reasons Martin noted. The components affected by the Moratorium - namely the Kernel, X and ALSA interfaces are not easy to build. For those of us on non-rolling can you provide an answer to Kevin's initial question, namely: what are the actual cases that triggered this concern? e.g. what currently relies on a recent kernel, X or alsa? for the same sort of reasons we can not make a all-SC decision, it's very hard to have a productive discusson without examples to demonstrate the problem which can then be analyzed and understood. since you mentioned custom patches, disable features and compilation failures, you must have at least a couple of them :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On Tue, Jun 7, 2011 at 8:06 AM, Aaron J. Seigo ase...@kde.org wrote: On Tuesday, June 7, 2011 06:19:52 Ben Cooksley wrote: The Moratorium would extend to all components of the KDE SC distribution. Hence kde-core-devel. imho this is impossible, for the reasons Martin noted. The components affected by the Moratorium - namely the Kernel, X and ALSA interfaces are not easy to build. For those of us on non-rolling can you provide an answer to Kevin's initial question, namely: what are the actual cases that triggered this concern? e.g. what currently relies on a recent kernel, X or alsa? I have two examples, Phonon and KWin. First Phonon. The Xine backend has now been deprecated, and has already broken in applications such as Amarok. The VLC backend gives me terrible skipping. Apparently upgrading to a newer version of VLC is needed to use it - but that depends on XCB 1.6. I only have 1.5. Phonon GStreamer - whilst installable, crashes applications on startup - and is therefore unusable. This effectively removes the capability to have multimedia playback using a KDE application. I tried (unsuccessfully unfortunately) to backport some of the fixes which would fix the skipping in Phonon VLC - but that didn't work. Next KWin. It currently depends upon Mesa 7.10. I have a local revert in a private local branch which reverts the dependency check code within KWin to continue to allow me to use compositing. Even though I have Mesa 7.8, I rarely experience KWin crashes - it has only crashed once in the past 2 months. I use an Intel Ironlake based graphics. This patch of mine works perfectly and does not cause any issues. Both of these are requiring new versions of X. for the same sort of reasons we can not make a all-SC decision, it's very hard to have a productive discusson without examples to demonstrate the problem which can then be analyzed and understood. since you mentioned custom patches, disable features and compilation failures, you must have at least a couple of them :) Whilst the compilation failures don't exist at the moment, I have one working patch - and several that have failed (and don't compile) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks Regards, Ben
Re: Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On Tue, Jun 7, 2011 at 8:42 AM, Martin Gräßlin mgraess...@kde.org wrote: On Tuesday 07 June 2011 08:29:51 Ben Cooksley wrote: Next KWin. It currently depends upon Mesa 7.10. I have a local revert in a private local branch which reverts the dependency check code within KWin to continue to allow me to use compositing. Even though I have Mesa 7.8, I rarely experience KWin crashes - it has only crashed once in the past 2 months. I use an Intel Ironlake based graphics. This patch of mine works perfectly and does not cause any issues. KWin does *not* depend on Mesa 7.10! KWin does not have any build dependencies on Mesa. There is an optional build dependency on OpenGL and XComposite/XDamage. This all is optional! If you use Mesa drivers there is a runtime requirement for at least Mesa 7.10, whose reasons have been explained to you on plasma-devel. Given what you demand this is out of scope as it is not a build dependency. It is just that you don't get the latest features when not having the correct runtime dependency. I might add that using different drivers (NVIDIA or ATI blob as well as GLES/EGL Mesa drivers) do not have this runtime requirement. It is also still possible to use KWin with XRender or without compositing at all. Btw. patches to have an environment variable to overwrite all checks are welcome. Please also note that I will add a runtime requirement to Mesa 7.11 as I have here on my system the start of the Wayland port which will be in 4.8 and requires Mesa 7.11. Now that is absolutely overboard. OpenSUSE 11.4 isn't even 3 months old. And has Mesa 7.10. You are effectively classifying a distribution as unsuitable for trunk development. You are now depending on components which aren't even in released distributions! (Note that having to live with a desktop without compositing isn't exactly what I would call usable for the long run) Cheers Martin Regards, Ben
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On Monday, June 06, 2011 05:48:41 PM Martin Gräßlin wrote: ... Personal opinion: I think it is impossible to want to run the latest software around an old stack. The overall FOSS world is rolling release with everything depending on everything. You cannot say it like that. It depends always on the developers of the respective applications. CMake is at 2.8.4 since 3 months or so, and we are still Ok with 2.6.4. Alex
Re: Re: Requested Moratorium on hard to build dependency bumps for KDE 5
Please also note that I will add a runtime requirement to Mesa 7.11 as I have here on my system the start of the Wayland port which will be in 4.8 and requires Mesa 7.11. Why would wayland support have any effect on runtime dependency on X11?
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
Am Mon, 6 Jun 2011 17:08:24 -0400 schrieb Maksim Orlovich m...@cornell.edu: Why would wayland support have any effect on runtime dependency on X11? http://groups.google.com/group/wayland-display-server/web/building-and-running-wayland Building mesa Wayland uses the mesa EGL stack, and all extensions required to run EGL on KMS are.. Cheers, Thomas
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
Am Tue, 7 Jun 2011 08:51:26 +1200 schrieb Ben Cooksley bcooks...@kde.org: You are effectively classifying a distribution No, distribution version vanilla - iff at all. (You still can develop on master, even run kwin - just not use OpenGL composited kwin from master then - that's not quite the same) Aside this, I'm not entirely firm in the OpenSuSE repositories, but they do provide mesa 7.10 for 11.3 which originally shipped 7.8. Given that this would be called (part of) a Graphics Driver elsewhere and accounting the rapid development of the KMS/X11/Mesa/E?GL(ES)? stack in the recent past as well as - well, quite some bugs regressions (tm), everything else could just as well be tagged as stupid. And afaik (Open)SuSE move towards a rolling release as well? You are now depending on as I have here on my system the start of the Wayland port which ^^ components which aren't even in released distributions! secret it's not even released by the mesa folks so far ;-) /secret (Note that having to live with a desktop without compositing isn't exactly what I would call usable for the long run) a) runtime mesa check does no way block compositing. b) Who says you've to use kwin from master then? Why should you _use_ (like: every day for reliable work) anything from master but the stuff you're actually into? Regarding your phonon/vlc issue: what's the configured sink in vlc? (please don't say standard - press ctrl+m and check the second tab output) Cheers, Thomas
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
Am Mon, 6 Jun 2011 18:33:28 -0400 schrieb Maksim Orlovich m...@cornell.edu: Sorry, my wording was poor: Might have been my reading as well. Your original question could have perfectly been read like the clarified one. OK, wayland needs recent Mesa at runtime, but I am not running Wayland; so why would I need to upgrade my mesa? This i do not know, since i don't have seen Martin's initial wayland supporting code, sorry :-( (I have a vague idea about what it could be, but am not gonna make a fool out of myself, speculating around while his insight is just a mail away ;-) Sorry, Thomas
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On Tue, Jun 7, 2011 at 5:12 PM, Martin Gräßlin mgraess...@kde.org wrote: - Ursprüngliche Mitteilung - On 6/6/11, Thomas Lübking thomas.luebk...@gmail.com wrote: Am Mon, 6 Jun 2011 17:08:24 -0400 schrieb Maksim Orlovich m...@cornell.edu: Why would wayland support have any effect on runtime dependency on X11? http://groups.google.com/group/wayland-display-server/web/building-and-running-wayland Building mesa Wayland uses the mesa EGL stack, and all extensions required to run EGL on KMS are.. Sorry, my wording was poor: OK, wayland needs recent Mesa at runtime, but I am not running Wayland; so why would I need to upgrade my mesa? It's not different to the current situation (and that's what I wanted to point out): With 4.7 there is a runtime requirement to Mesa 7.10 if you want to use the *optional* feauture of OpenGL compositing. With 4.8 there will be a runtime requirement to Mesa 7.11 if you want to use the *optional* feature of KWin being a Wayland server. I gather from this that X11 will be completely unaffected? Wanting to depend on unreleased software is unprecedented for a component of kde-workspace providing a commonly expected feature - and is something I find objectionable. Especially if the dependency offers no benefits to those of us whom recieve no benefit from the increase in dependencies. It should not affect the runtime requirements for X11, but if Mesa 7.11 gets released before our 4.8 dependency freeze, we have to depend on it. Can you please clarify what you mean by we *have* to depend on it? Does this mean which of the following: * CMake level check making KWin completely unavailable to people without Mesa 7.11 * Runtime level check making all compositing unavailable to people without Mesa 7.11 - regardless of whether it is X or Wayland * Runtime level check only concerning Wayland Either of options 1 and 2 are completely unacceptable under any circumstances - considering that people who will be developing for 4.8 will be doing so under distributions which ship 4.7 - which will probably only have Mesa 7.10. Compositing alters the way the window system operates and can expose bugs - and by imposing these dependencies you are inhibiting the ability of other developers to triage and fix bugs or other defects. Cheers Martin Regards, Ben
