On Friday, April 19, 2024 2:03:45 PM GMT+2 Luigi Toscano wrote: > We also have and we will continue to have applications which are not on this > schedule, and thus KDE will continue to be unfit as a general brand for > them. The work to reduce the dependencies improved with the move to Qt 6 > (for example the Frameworks-but-really-Plasma moved to Plasma), surely it > can be improved.
And this is fine. For these apps, they can still continue to depends on Framework as they wish and the API and ABI stability are still guaranteed. They won't have as often a feature release of Framework but I don't expect this to be a big issue as these apps already often prefer to depend on older framework release instead of pursuing the latest release. > > * We currently don't have a stable branch for Framework and it takes often > > up to> > > one month for fixes to be deployed. The Framework releases is also not > > in sync with either Gear nor Plasma while these two modules heavily > > make use of Framework and contribute to Framework. > > But the point of Frameworks is that it should be "always stable". This is unfortunately not the case. Errors happen and I feel like having a beta period shared with the rest of the stack and a patch release one week after the release would be really helpful for the stability of Framework. > > * We could have an unified LTS release including more than just Plasma. > > This is> > > something that distros have been asking for some time already because > > having just Plasma receiving bug-fixes but not Framework nor the apps > > is not that helpful. > Wasn't it said that LTS are difficult? I've heard different voices even from > Plasma. I'm not a big fan of doing LTS release either. I just think a LTS release of gear + plasma + framework would be better than one of just Plasma. > > * In term of promotion, it is very difficult to advertise the 3 releases > > because ........... > > Again, this will still leave out everything which does not happen to be part > of this 3 blocks. Which is fine. Apps outside of Gear have been doing their own release at their own pace with their own release announcement and will continue to do so. This proposal doesn't change that. It is not better or worse for them. > > * We won't have 3 different release teams but instead have a bigger one > > with a> > > bigger bus factor. We could also unify the tooling for doing this mass > > releases a bit. > > Releasing improved over time, and the tooling is definitely more unified > than before (I think Frameworks uses the same tool as Plasma). With the > discussion about improving the creating of tarballs directly from the tags, > this may be more a non-problem). It's improving and this is good. But you still need people to run the scripts at some interval, ensure that the builds are passing for everything and ping the correct people if not, move the translations to the correct branch in SVN, ... > > I do understand that there was valid reasons for splitting KDE Software > > Collection for Plasma 5 but I don't think this worked out. These were as > > far as I know the main arguments used for splitting the Software > > Collection. > > It doesn't mean moving back is the solution. Also, the split happened before > Qt5, and the reason are still there. The split is not solving the issues we were thinking it would solve and is additionally causing other issues. For me this is a clear indication that we need to rethink the split, that the current status quo is not working, and that we need to find a better solution. I'm proposing this proposal as a possible solution and indeed this might not be the only one, but this is only one I came up. Anyone is free to propose counter proposal on how to improve the situation ;) > > * Trying to move away from "KDE" being recognized as the software instead > > of the> > > community. This unfortunately didn't really work out, everyone is still > > using KDE to refer to the desktop. Even distros call their edition > > "KDE" and I don't blame them, it's difficult to find a better term than > > that as for example "Fedora KDE Spin" not only contains Plasma but also > > a lot of KDE apps. Splitting the releases won't help with that, we need > > to find a better approach or just let it go and accept that people will > > keep using KDE to describe the desktop/software. > > And again, we have and will have stuff which does not fit that. The main > problem is the Desktop which is seen as "KDE". People use "KDE" to refer to the "core" components and this includes stuff like Dolphin, Kate and Okular, it's not only the desktop. > Maybe it will take just more time and another generation of people. I don't think so and even if it did require more time, do we want to wait another decade and see if the situation improve? > > * Better promotion of our apps outside of Plasma. This is a valid point > > but I think> > > pursuing our current strategy of putting our apps in many app store to > > be more effective. We could also show the platforms support of each > > applications more prominently in our releases announcements like we > > already do on apps.kde.org (e.g. https://apps.kde.org/okular/). > > Generally Plasma releases fare a lot better in term of promotion than > > the gear announcements and showing the applications on an unified > > announcement would likely help spread the words about our applications > > better. > > People will still think that "this is for Plasma only". I think people will still that either way. It's by pushing our apps on more stores (Windows Store, F-Droid, Flathub), improving the compatibility of our apps on these systems (e.g .styling or system integration), better advertise our apps for these platforms in our public communication (e.g. the latest blog post about Kate was great) that we will manage to change this mentality that KDE apps are only for Plasma. > > * Helps with outside usage of our frameworks. These didn't get as much > > success> > > as we were hoping when splitting. I think having a stable branch for > > Framework might help but this is only a guess. It would be interesting > > to know of cases where people considered using some Framework and to > > know why they decided against or for it and if this proposal would > > helps or not. > > Are you sure that not having a stable branch of Frameworks is the problem? I > would argue that having it again as part of one big thing will make people > run away even more. From the developer side, Framework will still be a "product" from the KDE with its own subpage on api.kde.org, its marketing and tutorials on develop.kde.org, it's stable API/ABI guarantees and everything else that makes framework great. In addition it will gain beta releases and regular bug-fixing only releases, which should improve the stability and the attractiveness for external developers to use the frameworks. From an end user side, the user facing change will be mentioned in the unified announcement instead of as it often happens being forgotten because it is not relevant to a specific app or to Plasma and doesn't really fit in either of these announcements. > I appreciate the time and I see there are issues, but I don't think we > should pursue this proposal, as it will just reintroduce other import > problem and not help with still relevant goals like "all about the apps". Thanks for the feedback
signature.asc
Description: This is a digitally signed message part.
