romangg added a comment.
In D29028#654526 <https://phabricator.kde.org/D29028#654526>, @tcanabrava wrote: > I understand David's point: Wrapland project has one developer and we don't know how successful it will be, while the other backends have developers. What would happen if you suddenly quit / disappear and the project dies? Then kscreen will have a folder of dead code. > > This is a Plugin, it can live in any folder / project, you already forked KWinFT, create a new project to put this KScreen plugin, we can't scale to N projects adding code as plugins that will need to be maintained for quite a while in the future. > > > Come on man, do you really want to make this ugly? I thought we would still treat each other with respect David. :( > > Your words. His words are technical, Please don't distort things and make it about you. I haven't noticed much technical words in what was said. I did ask about the headers-only proposal that was of technical nature. Also the tone made it seem to me personal, but that sadly might have been just what is often the default tone in Plasma reviews (no finger pointing intended, I have been guilty of that in the past too). >> Which "established practices" does this not satisfy? > > It's an external library that does not solve any problem within the plasma, nor adds value to plasma users. It's an experimental project, with only one developer, not stable, not ready, not core. You can see on this picture that we are not blocking your project here because of $excuse, but this is something that we do if the project is not core, please check the date. > F8253102: image.png <https://phabricator.kde.org/F8253102> > > There's more information on the full phabricator ticket: > https://phabricator.kde.org/D20265 I looked at that and suspected to see a hard dependency there. But it also is only an optional dependency with a check if the package is available. So I'm wondering what are the rules if something can become an //optional// dependency for a Plasma project? Is this written down somewhere? >> How would that look in detail? > > That will give you the possibility to create plugins for KScreen that are not bound to KScreen code, then you can create your project in gitlab and have different release schedules, in a way that: > 1 - The plugin code is independent to KDE Releases > 2 - We have a clear separation on project responsabilities > 3 - Being independent means that it can also test with experimental libraries. > >> Why is this even relevant? > > We need to be sure that the code of the project will always be buildable through the lifespan of Plasma 5.19, and right now we can't guarantee it. Since the dependency is optional you are guaranteed to be able to build libkscreen by removing Wrapland or not installing it in the first place. Also Wrapland will have a 0.519.0 release as it has now a 0.518.0 release. Releases will be synced up with Plasma releases. Otherwise the KWinFT-Plasma integration would not work anyway. > Create this code outside of KSCreen as a plugin. We will gladly accept code that install the Interface Headers to make that possible. :) I think that this is unnecessary complicated because releases will be synced, but I can live with it. Would this mean only the first patch of this patch series would go in and I export the `wayland_interface.h` and `waylandoutput.h` headers (they are being used in the plugins)? Thanks for taking the time Tomaz. REPOSITORY R110 KScreen Library REVISION DETAIL https://phabricator.kde.org/D29028 To: romangg, #plasma, davidedmundson, apol Cc: anthonyfieroni, tcanabrava, apol, davidedmundson, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, ahiemstra, mart
