[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: Proposal unify back our release schedules
From:       Luigi Toscano <luigi.toscano () tiscali ! it>
Date:       2024-04-19 12:03:45
Message-ID: 13582279-000b-bed5-2ed8-e5597c59002a () tiscali ! it
[Download RAW message or body]

(apologize, resending, I've missed a CC)

Carl Schwan ha scritto:
> Hello Community,
> 
> I know this might be a controversial idea, but I would like to propose reunify
> our release schedules. I feel like splitting our releases schedules between
> Frameworks, Plasma and Gear is not working as well as we intended it to be when
> we split the releases schedules for Plasma 5. This is for multiple reasons:
> 
> * We end up with 3 different products which are released at different times but
>   are connected together. Apps and Plasma both need Framework, Plasma needs some
>   packages from gear like kio-extra, Gear needs some package from Plasma like
>   Breeze. Coordinating all these inter-groups dependencies is complex and was one
>   the reason we had to do a megarelease for Plasma 6. Also for the end user, one
>   product is a lot easier to understand.

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.

> * This results in very frequent releases which creates a lot of work for distros
>   and talking with some distro maintainers they seems to agree that having a big
>   releases every 4 months is better than having constantly a new minor or major
>   release from either Framework, Gear or Plasma.




> 
> * 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".

> 
> * 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.


> 
> * In term of promotion, it is very difficult to advertise the 3 releases because
>   combined we have an important release of either Gear, Plasma or Framework every
>   few weeks. This is too frequent and often while a combined announcement would
>   have enough content to be published in a tech newspaper. When splitting the content
>   accross 2 announcements (Gear and Plasma), we reduce the content per
>   announcement and this makes it less interesting for the journalists to write
>   about us. This doesn't come from me, this is that some journalists directly
>   told me.

Again, this will still leave out everything which does not happen to be part
of this 3 blocks.


> 
> * 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).

> 
> 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.

> 
> * 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".
Maybe it will take just more time and another generation of people.

> 
> * 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".


> * 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.



> 
> In effect this proposal would mean:
> 
> * We do one major release every 4 months and then minor releases with a frequency
>   based on the Fibonacci numbers as this releases cycle works very well for
>   Plasma. Naming could be either YY.MM or Major.Minor.Path. We could unify that
>   for one or the other one. Or let each component keep their current versioning
>   scheme depending whether we want to merge Plama and Gear as product or
>   keep it separate. I'm a bit undecided about this.
> 
> * "KDE Framework" will still exists as an entity and its ABI and API
>   compatibility requirement. Only change is the release frequency and the introduction
>   of a stable branch in sync with the other components.
> 
> * Only have one release announcement on our website. We can call it Megarelease
>   6.XX like we did for Plasma 6/Gear 24.02 or find a better name. I would avoid reusing
>   Software Collection first because the name is quite technical and second because
>   these was already used in the past.
> 
> Currently this is just a proposal, not a vote proposal or anything like that. I'll be
> happy to receive positive or negative feedback on this idea.

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".

-- 
Luigi
[prev in list] [next in list] [prev in thread] [next in thread]