KDE Gear and KF6

[Albert Astals Cid]

El dimecres, 8 de març de 2023, a les 7:50:22 (CET), Julius Künzel va 
escriure:
> 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.

And what's the point of all that "do releases independent of KDE Gear and join 
back later" bureaucracy?

It's really more work for everyone and no real gain.

Cheers,
  Albert

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