Hi, 08.03.2023 00:21:31 Albert Astals Cid <[email protected]>:
> 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 <[email protected]> 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 <[email protected]> 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
