KDE Gear and KF6

[Julius Künzel]

Hi,

08.03.2023 00:21:31 Albert Astals Cid <aacid at kde.org>:

> El dimarts, 7 de març de 2023, a les 23:39:07 (CET), Neal Gompa va escriure:
>> On Tue, Mar 7, 2023 at 5:29 PM Albert Astals Cid <aacid at kde.org> wrote:
>>> El dimarts, 7 de març de 2023, a les 1:09:39 (CET), Neal Gompa va
> escriure:
>>>> On Mon, Mar 6, 2023 at 11:06 AM Volker Krause <vkrause at kde.org> wrote:
>>>>> Hi,
>>>>> 
>>>>> with Plasma switched to KF6, the question what to do for other modules
>>>>> is
>>>>> coming up as well. Manually released modules have various options
>>>>> there I
>>>>> guess, but for everything covered by the KDE Gear release automation
>>>>> we
>>>>> probably want to standardize the process to not break automation too
>>>>> much,
>>>>> regarding branching at least (for the timeline I expect we need more
>>>>> flexibility).
>>>>> 
>>>>> I have seen several scenarios mentioned/discussed so far:
>>>>> 
>>>>> (1) The switch to 6 happens within one release cycle. That's the easy
>>>>> case
>>>>> and probably has minimal to no impact on release automation. Unlikely
>>>>> to
>>>>> be relevant for 23.08 already, but probably relevant starting from
>>>>> 23.12.
>>>>> 
>>>>> (2) Switching needs more than one cycle. This is more likely to be
>>>>> relevant
>>>>> for 23.08 already.
>>>>> 
>>>>> (2a) The migration happens in a separate kf6 branch:
>>>>> - 3 concurrent branches
>>>>> + no impact on the release automation
>>>>> + continuous releases for users
>>>>> 
>>>>> (2b) The migration happens in the master branch, additional patch
>>>>> releases
>>>>> are made from the last release branch (ie. instead of e.g. 23.08.0
>>>>> there
>>>>> would be a 23.04.4)
>>>>> + no change to existing branching patterns for developers
>>>>> - more significant change to release automation
>>>>> + continuous releases for users
>>>>> 
>>>>> (2c) Migration in master branch, so further releases
>>>>> + no changes to existing branching patterns
>>>>> + presumably minimal impact to release automation
>>>>> - no bugfix releases for users

>From a Kdenlive perspective I would say 2b or 2a are the best choices.

>>>>> 
>>>> 
>>>> I think 2b or 2c would make sense, since that would mirror how things
>>>> are being done for kf5 and Plasma/5.27.
>>> 
>>> You can not compare Plasma or KDE Frameworks to KDE Gear.
>>> 
>>> Plasma and KDE Frameworks are "single products", they need all to be
>>> ported at once and at the same time.
>>> 
>>> KDE Gear are independent products that can [mostly] be ported at their own
>>> speed. Also the ratio of developer/line of code is much smaller in general
>>> in KDE Gear.
>>> 
>>> For that I don't think the same solution that makes sense for one thing
>>> doesn't necessarily make sense for the other.
>> 
>> It's only good until experience incoherence catches up for us. Keep in
>> mind that KDE Gear depends on both Qt 5 and KF5 today. Once both of
>> those aren't supported anymore, that's going to be a big problem for
>> KDE Gear.
> 
> That's not going to happen anytime soon, is it?
> 
>> I would say that it makes sense to consider prioritizing
>> those migrations and apps that don't move just get dropped from the
>> release service until they update.
> 
> Yes, that's what we will do, just not in a 4 months cycle. Maybe let's say in
> 2 years.

After the first KF6 release (which is still a few months ahead) 2 release cycles for KDE Gear apps to port seems realistic too me even for big apps (like Kdenlive). Preparation for Qt6 is already possible since a while. Maybe give one additional cycle buffer, but overall 2 years (=6 release cycles) is too much in my opinion.
As already stated: if an app is not able to do the port within that time, it is always possible to do releases independent of KDE Gear and join back later.

> 
>> We had problems for *years* with apps depending on Qt4+kdelibs4 and
>> later shim libraries until people *finally* gave up on some of those
>> apps. Maybe we should do that from the beginning this time.
> 
> Did we? I recall much more problems with people doing "it compiles with Qt5
> shipit" and in fact nothing really worked than the fact that applications were
> using well known versions of things that worked for a few more months.
> 
> Cheers,
>   Albert

Cheers,
Julius