Proposal unify back our release schedules

[Carl Schwan]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20240419/751d9da3/attachment-0001.sig>