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

List:       kde-release-team
Subject:    Re: KDE Gear and KF6
From:       Julius_Künzel <jk.kdedev () smartlab ! uber ! space>
Date:       2023-03-08 6:50:22
Message-ID: c94b6730-0cc1-4277-8a72-31027a07ad23 () smartlab ! uber ! space
[Download RAW message or body]

Hi,

08.03.2023 00:21:31 Albert Astals Cid <aacid@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@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@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


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