Re: Move Calligra to release service

[Albert Astals Cid]

El dijous, 22 d’agost del 2024, a les 0:58:16 (CEST), Albert Astals Cid va 
escriure:
> El dijous, 15 d’agost del 2024, a les 10:30:10 (CEST), Carl Schwan va
> 
> escriure:
> > Sorry I missed this email.
> > 
> > Calligra kind of works already. Sure it doesn't support every odf feature
> > but all the basic features are fully usable. Most of my recent work in
> > Calligra has been on Qt6 port, some code modernization and redesigning the
> > UI.
> > 
> > Calligra does need more contributors but without regular release, I don't
> > see this happening. I am hoping that the redesigned UI will also help.
> > 
> > Also releasing it in Gear, doesn't mean that we should recommend distro to
> > ship it per default, or at least not yet ;)
> 
> Ok, I am still not 100% convinced but I won't block on this.

No one has complained, so added for KDE Gear 24.12.

Cheers,
  Albert

> 
> Cheers,
>   Albert
> 
> > Cheers,
> > Carl
> > 
> > PS: Send from mobile, sorry for the formatting
> > 
> > On Tue, Aug 6, 2024, at 12:30 AM, Albert Astals Cid wrote:
> > > El divendres, 26 de juliol del 2024, a les 11:29:05 (CEST), Carl Schwan
> > > va
> > > 
> > > escriure:
> > > > Hi,
> > > > 
> > > > I ported some times ago Calligra to Qt6 and I would propose adding
> > > > Calligra
> > > > to release service starting with 24.12. I wanted to do do that already
> > > > for
> > > > 24.08 but forgot, so I probably will soon do an independent release.
> > > > 
> > > > By Calligra, I mean only the office/calligra repo on invent, not any
> > > > of
> > > > the
> > > > project who spitted from the main repo (e.g. Kexi, Calligra Plan).
> > > 
> > > I was waiting for someone to be the bad-person, but I guess I'm the
> > > designed bad-person, so here it goes
> > > 
> > > Can we collectively maintain Calligra to a degree it "kind of works"?
> > > 
> > > We have our fair share (more than I'd like) of applications without an
> > > specific maintainer in KDE Gear, but their size (relatively
> > > small/medium)
> > > makes it so that if we want to fix bugs or implement small features on
> > > them
> > > it's relatively easy.
> > > 
> > > On the other hand Calligra seems to be like 10 times bigger than Okular.
> > > Can we commit to collectively maintain it?
> > > 
> > > Cheers,
> > > 
> > >   Albert
> > >   
> > > > Cheers,
> > > > Carl

Re: Add Crow Translate to KDE Gear

[Albert Astals Cid]

El dilluns, 2 de setembre del 2024, a les 23:52:31 (CEST), Hennadii 
Chernyshchyk va escriure:
> Great, thanks!

Please keep the mailing list in copy.

> 
> > Please make sure crow-translate has an automatically updating version
> 
> number.
> 
> Where can I read more about how to prepare the project?

https://community.kde.org/Guidelines_and_HOWTOs/Application_Versioning

Cheers,
  Albert

> I especially wondering how "releases" section updated in metainfo.xml:
> https://invent.kde.org/office/crow-translate/-/blob/master/data/org.kde.Crow
> Translate.metainfo.xml?ref_type=heads#L289
> вт, 3 сент. 2024 г. в 00:47, Albert Astals Cid :
> > El dijous, 22 d’agost del 2024, a les 0:55:57 (CEST), Albert Astals Cid va
> > 
> > escriure:
> > > El dimecres, 14 d’agost del 2024, a les 17:39:59 (CEST), Hennadii
> > > Chernyshchyk
> > > 
> > > va escriure:
> > > > So do you still want me to have a few releases on my own?
> > > > I'm just not sure if it's necessary for a relatively feature-complete
> > 
> > app.
> > 
> > > > But I will do as you say :)
> > > 
> > > I'm relatively convinced I guess, let's see if someone else has an
> > 
> > opinion.
> > 
> > 
> > Ok, no one has complained, added.
> > 
> > Please make sure crow-translate has an automatically updating version
> > number.
> > 
> > Cheers,
> > 
> >   Albert
> >   
> > > Cheers,
> > > 
> > >   Albert
> > >   
> > > > ср, 7 авг. 2024 г. в 10:42, Hennadii Chernyshchyk  > > > 
> > > > > Makes sense!
> > > > > But the app is not newly developed, I made it in 2018. I would say
> > 
> > that
> > 
> > > > > it's feature-complete.
> > > > > There is always room for new features, but I would say that nothing
> > > > > critical is missing.
> > > > > 
> > > > > ср, 7 авг. 2024 г. в 01:51, Albert Astals Cid :
> > > > >> El dilluns, 5 d’agost del 2024, a les 20:59:29 (CEST), Hennadii
> > > > >> Chernyshchyk
> > > > >> 
> > > > >> va escriure:
> > > > >> > Hi! The app <https://invent.kde.org/office/crow-translate> has
> > > > >> > recently
> > > > >> > passed the review phase
> > > > >> > <https://invent.kde.org/office/crow-translate/-/issues/699> and I
> > > > >> > would
> > > > >> > like to ask to add it to KDE Gear. What is needed for it from me?
> > > > >> 
> > > > >> For new apps *personally* I always suggest to do a few releases on
> > 
> > your
> > 
> > > > >> own
> > > > >> because it allows for much faster feature turn-around than KDE Gear
> > > > >> that
> > > > >> has a
> > > > >> very strict 3 months for new features schedule, that is usually
> > > > >> fine
> > > > >> for
> > > > >> "established" apps but for something new you may very well find
> > > > >> that
> > > > >> there's
> > > > >> that obvious feature missing that everyone needs and now you can't
> > 
> > add
> > 
> > > > >> it
> > > > >> until 3 months in the future.
> > > > >> 
> > > > >> Cheers,
> > > > >> 
> > > > >>   Albert
> > > > >>   
> > > > >> > I followed the instructions from the wiki
> > > > >> > <
> > 
> > https://community.kde.org/Policies/Application_Lifecycle#Releasing>.

Re: Remove Akonadi Notes from 24.12 release

[Albert Astals Cid]

El dilluns, 26 d’agost del 2024, a les 18:26:17 (CEST), Carl Schwan va 
escriure:
> Hi,
> 
> For 24.12, the KDE PIM wants to remove Akonadi Notes repo as it is now not
> used anymore.
> 
> I created https://invent.kde.org/sysadmin/release-tools/-/merge_requests/55

Makes sense I guess.

Merged, anyone that really wants to keep it can convince us to add it back 
before the release.

Cheers,
  Albert

> 
> Cheers,
> Carl

Re: Add Crow Translate to KDE Gear

[Albert Astals Cid]

El dilluns, 2 de setembre del 2024, a les 23:47:49 (CEST), Albert Astals Cid 
va escriure:
> El dijous, 22 d’agost del 2024, a les 0:55:57 (CEST), Albert Astals Cid va
> 
> escriure:
> > El dimecres, 14 d’agost del 2024, a les 17:39:59 (CEST), Hennadii
> > Chernyshchyk
> > 
> > va escriure:
> > > So do you still want me to have a few releases on my own?
> > > I'm just not sure if it's necessary for a relatively feature-complete
> > > app.
> > > But I will do as you say :)
> > 
> > I'm relatively convinced I guess, let's see if someone else has an
> > opinion.
> 
> Ok, no one has complained, added.
> 
> Please make sure crow-translate has an automatically updating version
> number.

Actuall, i just realize crow-translate is based on Qt5.

I am 0% convinced we should be adding new apps to KDE Gear that are based on 
Qt5 so i am leaning towards un-adding it.

What's your plan for a Qt6 port?

Best Regards,
  Albert

> 
> Cheers,
>   Albert
> 
> > Cheers,
> > 
> >   Albert
> >   
> > > ср, 7 авг. 2024 г. в 10:42, Hennadii Chernyshchyk :
> > > > Makes sense!
> > > > But the app is not newly developed, I made it in 2018. I would say
> > > > that
> > > > it's feature-complete.
> > > > There is always room for new features, but I would say that nothing
> > > > critical is missing.
> > > > 
> > > > ср, 7 авг. 2024 г. в 01:51, Albert Astals Cid :
> > > >> El dilluns, 5 d’agost del 2024, a les 20:59:29 (CEST), Hennadii
> > > >> Chernyshchyk
> > > >> 
> > > >> va escriure:
> > > >> > Hi! The app <https://invent.kde.org/office/crow-translate> has
> > > >> > recently
> > > >> > passed the review phase
> > > >> > <https://invent.kde.org/office/crow-translate/-/issues/699> and I
> > > >> > would
> > > >> > like to ask to add it to KDE Gear. What is needed for it from me?
> > > >> 
> > > >> For new apps *personally* I always suggest to do a few releases on
> > > >> your
> > > >> own
> > > >> because it allows for much faster feature turn-around than KDE Gear
> > > >> that
> > > >> has a
> > > >> very strict 3 months for new features schedule, that is usually fine
> > > >> for
> > > >> "established" apps but for something new you may very well find that
> > > >> there's
> > > >> that obvious feature missing that everyone needs and now you can't
> > > >> add
> > > >> it
> > > >> until 3 months in the future.
> > > >> 
> > > >> Cheers,
> > > >> 
> > > >>   Albert
> > > >>   
> > > >> > I followed the instructions from the wiki
> > > >> > <https://community.kde.org/Policies/Application_Lifecycle#Releasing
> > > >> > >.

Re: Add Crow Translate to KDE Gear

[Albert Astals Cid]

El dijous, 22 d’agost del 2024, a les 0:55:57 (CEST), Albert Astals Cid va 
escriure:
> El dimecres, 14 d’agost del 2024, a les 17:39:59 (CEST), Hennadii
> Chernyshchyk
> va escriure:
> > So do you still want me to have a few releases on my own?
> > I'm just not sure if it's necessary for a relatively feature-complete app.
> > But I will do as you say :)
> 
> I'm relatively convinced I guess, let's see if someone else has an opinion.


Ok, no one has complained, added.

Please make sure crow-translate has an automatically updating version number.

Cheers,
  Albert

> 
> Cheers,
>   Albert
> 
> > ср, 7 авг. 2024 г. в 10:42, Hennadii Chernyshchyk :
> > > Makes sense!
> > > But the app is not newly developed, I made it in 2018. I would say that
> > > it's feature-complete.
> > > There is always room for new features, but I would say that nothing
> > > critical is missing.
> > > 
> > > ср, 7 авг. 2024 г. в 01:51, Albert Astals Cid :
> > >> El dilluns, 5 d’agost del 2024, a les 20:59:29 (CEST), Hennadii
> > >> Chernyshchyk
> > >> 
> > >> va escriure:
> > >> > Hi! The app <https://invent.kde.org/office/crow-translate> has
> > >> > recently
> > >> > passed the review phase
> > >> > <https://invent.kde.org/office/crow-translate/-/issues/699> and I
> > >> > would
> > >> > like to ask to add it to KDE Gear. What is needed for it from me?
> > >> 
> > >> For new apps *personally* I always suggest to do a few releases on your
> > >> own
> > >> because it allows for much faster feature turn-around than KDE Gear
> > >> that
> > >> has a
> > >> very strict 3 months for new features schedule, that is usually fine
> > >> for
> > >> "established" apps but for something new you may very well find that
> > >> there's
> > >> that obvious feature missing that everyone needs and now you can't add
> > >> it
> > >> until 3 months in the future.
> > >> 
> > >> Cheers,
> > >> 
> > >>   Albert
> > >>   
> > >> > I followed the instructions from the wiki
> > >> > <https://community.kde.org/Policies/Application_Lifecycle#Releasing>.

Re: Move Calligra to release service

[Albert Astals Cid]

El dijous, 15 d’agost del 2024, a les 10:30:10 (CEST), Carl Schwan va 
escriure:
> Sorry I missed this email.
> 
> Calligra kind of works already. Sure it doesn't support every odf feature
> but all the basic features are fully usable. Most of my recent work in
> Calligra has been on Qt6 port, some code modernization and redesigning the
> UI.
> 
> Calligra does need more contributors but without regular release, I don't
> see this happening. I am hoping that the redesigned UI will also help.
> 
> Also releasing it in Gear, doesn't mean that we should recommend distro to
> ship it per default, or at least not yet ;)

Ok, I am still not 100% convinced but I won't block on this.

Cheers,
  Albert

> 
> Cheers,
> Carl
> 
> PS: Send from mobile, sorry for the formatting
> 
> On Tue, Aug 6, 2024, at 12:30 AM, Albert Astals Cid wrote:
> > El divendres, 26 de juliol del 2024, a les 11:29:05 (CEST), Carl Schwan va
> > 
> > escriure:
> > > Hi,
> > > 
> > > I ported some times ago Calligra to Qt6 and I would propose adding
> > > Calligra
> > > to release service starting with 24.12. I wanted to do do that already
> > > for
> > > 24.08 but forgot, so I probably will soon do an independent release.
> > > 
> > > By Calligra, I mean only the office/calligra repo on invent, not any of
> > > the
> > > project who spitted from the main repo (e.g. Kexi, Calligra Plan).
> > 
> > I was waiting for someone to be the bad-person, but I guess I'm the
> > designed bad-person, so here it goes
> > 
> > Can we collectively maintain Calligra to a degree it "kind of works"?
> > 
> > We have our fair share (more than I'd like) of applications without an
> > specific maintainer in KDE Gear, but their size (relatively small/medium)
> > makes it so that if we want to fix bugs or implement small features on
> > them
> > it's relatively easy.
> > 
> > On the other hand Calligra seems to be like 10 times bigger than Okular.
> > Can we commit to collectively maintain it?
> > 
> > Cheers,
> > 
> >   Albert
> >   
> > > Cheers,
> > > Carl

Re: Move Plasma Dialer and Spacebar to Plasma release

[Albert Astals Cid]

El dijous, 15 d’agost del 2024, a les 10:41:53 (CEST), Carl Schwan va 
escriure:
> Hi,
> 
> Me again, this time to ask to move Plasma Dialer and Spacebar to the Plasma
> release cycle (or gear release cycle).
> 
> I did the two last releases 23.01 and 24.08 for dialer and 23.01 and 24.05
> for spacebar, and as you might guess from the version numbers, the
> frequency of the release as been quite bad. Moving to a release service
> would help a lot.
> 
> This could either go in the plasma release because both applications are
> core component of Plasma Mobile and additional Dialer has an optional
> dependency on plasma wayland protocols. Or in Gear because that's where
> most plasma mobile apps are. I don't really have a preference.

I don't have a preference either.

We can do KDE Gear I guess if no one disagrees.

Cheers,
  Albert

> 
> Cheers,
> Carl

Re: Add Crow Translate to KDE Gear

[Albert Astals Cid]

El dimecres, 14 d’agost del 2024, a les 17:39:59 (CEST), Hennadii Chernyshchyk 
va escriure:
> So do you still want me to have a few releases on my own?
> I'm just not sure if it's necessary for a relatively feature-complete app.
> But I will do as you say :)

I'm relatively convinced I guess, let's see if someone else has an opinion.

Cheers,
  Albert

> 
> ср, 7 авг. 2024 г. в 10:42, Hennadii Chernyshchyk :
> > Makes sense!
> > But the app is not newly developed, I made it in 2018. I would say that
> > it's feature-complete.
> > There is always room for new features, but I would say that nothing
> > critical is missing.
> > 
> > ср, 7 авг. 2024 г. в 01:51, Albert Astals Cid :
> >> El dilluns, 5 d’agost del 2024, a les 20:59:29 (CEST), Hennadii
> >> Chernyshchyk
> >> 
> >> va escriure:
> >> > Hi! The app <https://invent.kde.org/office/crow-translate> has recently
> >> > passed the review phase
> >> > <https://invent.kde.org/office/crow-translate/-/issues/699> and I would
> >> > like to ask to add it to KDE Gear. What is needed for it from me?
> >> 
> >> For new apps *personally* I always suggest to do a few releases on your
> >> own
> >> because it allows for much faster feature turn-around than KDE Gear that
> >> has a
> >> very strict 3 months for new features schedule, that is usually fine for
> >> "established" apps but for something new you may very well find that
> >> there's
> >> that obvious feature missing that everyone needs and now you can't add it
> >> until 3 months in the future.
> >> 
> >> Cheers,
> >> 
> >>   Albert
> >>   
> >> > I followed the instructions from the wiki
> >> > <https://community.kde.org/Policies/Application_Lifecycle#Releasing>.

Re: Moving KUnifiedPush to KDE Gear

[Albert Astals Cid]

El dijous, 15 d’agost del 2024, a les 17:06:30 (CEST), Volker Krause va 
escriure:
> On Dienstag, 16. April 2024 20:52:14 MESZ Volker Krause wrote:
> > On Montag, 15. April 2024 23:22:00 CEST Albert Astals Cid wrote:
> > > El dilluns, 15 d’abril del 2024, a les 18:06:30 (CEST), Volker Krause va
> > > 
> > > escriure:
> > > > Hi,
> > > > 
> > > > I'd like to propose the KUnifiedPush library
> > > > (https://invent.kde.org/libraries/ kunifiedpush) for inclusion in KDE
> > > > Gear.
> > > 
> > > My answer when someone else asked the same question for other apps on
> > > Matrix this morning.
> > > 
> > > I'd say feels a bit late with dependency freeze in 3 days and freeze
> > > freeze
> > > in 10.
> > > 
> > > I'd prefer 2 weeks before dependency freeze, could live with 2 weeks
> > > before
> > > freeze freeze. [1]
> > > 
> > > Can we wait for 24.08 for this?
> > 
> > Fair enough, we can fill the gap with manual releases if needed.
> 
> Uh, just tried to backport a fix here and noticed the lack of a 24.08
> branch, looks like we missed this?

Apologies, this is totally my fault.

I even have a "Double check that all additions/removals to modules.git as per 
release-team discussions have been done" in 
https://invent.kde.org/teams/release-service/issues/-/issues/31

But failed to remember this :/

> Way too late now I assume, I'll submit an MR for 24.12 then.

I would say so, yeah :/

Best Regards,
  Albert

> Regards,
> Volker

KDE Gear 24.08 RC release

[Albert Astals Cid]

Packages are available at the usual locations.

Everything compiles fine for me.

Cheers,
  Albert

Re: Add Crow Translate to KDE Gear

[Albert Astals Cid]

El dilluns, 5 d’agost del 2024, a les 20:59:29 (CEST), Hennadii Chernyshchyk 
va escriure:
> Hi! The app  has recently
> passed the review phase
>  and I would
> like to ask to add it to KDE Gear. What is needed for it from me?

For new apps *personally* I always suggest to do a few releases on your own 
because it allows for much faster feature turn-around than KDE Gear that has a 
very strict 3 months for new features schedule, that is usually fine for 
"established" apps but for something new you may very well find that there's 
that obvious feature missing that everyone needs and now you can't add it 
until 3 months in the future.

Cheers,
  Albert


> I followed the instructions from the wiki
> .

Re: Move Calligra to release service

[Albert Astals Cid]

El divendres, 26 de juliol del 2024, a les 11:29:05 (CEST), Carl Schwan va 
escriure:
> Hi,
> 
> I ported some times ago Calligra to Qt6 and I would propose adding Calligra
> to release service starting with 24.12. I wanted to do do that already for
> 24.08 but forgot, so I probably will soon do an independent release.
> 
> By Calligra, I mean only the office/calligra repo on invent, not any of the
> project who spitted from the main repo (e.g. Kexi, Calligra Plan).

I was waiting for someone to be the bad-person, but I guess I'm the designed 
bad-person, so here it goes

Can we collectively maintain Calligra to a degree it "kind of works"?

We have our fair share (more than I'd like) of applications without an 
specific maintainer in KDE Gear, but their size (relatively small/medium) 
makes it so that if we want to fix bugs or implement small features on them 
it's relatively easy.

On the other hand Calligra seems to be like 10 times bigger than Okular. Can 
we commit to collectively maintain it?

Cheers,
  Albert

> 
> Cheers,
> Carl

KDE Gear 24.08 Beta release

[Albert Astals Cid]

Packages are available at the usual locations.

Everything compiles fine for me.

Cheers,
  Albert

Re: The Umbrello/kdevelop problem

[Albert Astals Cid]

El dimarts, 23 de juliol del 2024, a les 12:44:29 (CEST), Ralf Habacker va 
escriure:
> Am 22.07.24 um 22:55 schrieb Albert Astals Cid:
> > Which features are lost in Umbrello when kdev-* is not available?
> 
> kdev is used for providing php language support.
> 
> from
> https://invent.kde.org/sdk/umbrello/-/blob/master/CMakeLists.txt?ref_type=he
> ads#L112
> 
> if(BUILD_PHP_IMPORT)
>  find_package(KDevelop-PG-Qt)
>  find_package(KDevPlatform ${KDEV_MIN_VERSION} COMPONENTS
> ${KDEV_COMPONENTS})
> endif()
> 
> > For 24.08 would it make sense to just copy the necessary kdev-* code to
> > umbrello or that's crazyness?

You didn't answer this question :)

Does that seem like a reasonable way to fix the problem? Or should we just let 
people use the old kdevelop or not have php support?

We need to figure out what to do at least CI wise because it's currently 
failing
https://invent.kde.org/sdk/umbrello/-/pipelines/739701
If you are OK with disabling the php support for now for 24.08 that seems ok 
for me too.

Cheers,
  Albert

> > 
> > Is an umbrello KF6 port in sight for 24.12?
> 
> I am not currently aware of this.
> 
> Cheers
> Ralf

The Umbrello/kdevelop problem

[Albert Astals Cid]

KDevelop & friends just migrated to KF6-only in time for the KDE Gear 24.08

Unfortutantely we collectively forgot Umbrello uses KDevelop stuff too and 
Umbrello is in KF5.

It compiles locally fine without kdevelop (with loss of features I guess) but 
it's failing on CI 
https://invent.kde.org/sdk/umbrello/-/pipelines/737657

Which features are lost in Umbrello when kdev-* is not available?

For 24.08 would it make sense to just copy the necessary kdev-* code to 
umbrello or that's crazyness?

Is an umbrello KF6 port in sight for 24.12?

Cheers,
  Albert

Re: Dependency freeze exception request for kdevelop & kdev-php on kdevelop-pg-qt

[Albert Astals Cid]

El diumenge, 21 de juliol del 2024, a les 21:49:50 (CEST), Friedrich W. H. 
Kossebau va escriure:
> Hi,
> 
> I have to request an exception to the Gear 24.08 dependency freeze for
> kdevelop & kdev-php:
> 
> There is a hard dependency on a yet to be released version of kdevelop-pg-qt
> (on own release schedule, not part of Gear).
> That sadly so far was shadowed by KDE CI setup and local installations of
> development versions.
> 
> See https://invent.kde.org/kdevelop/kdev-php/-/merge_requests/21 for a
> respective dependency bump prepared for kdev-php.
> One for kdevelop would follow once the plan is approved.
> kdevelop-pg-qt 2.3 release would also happen the next days by me.

Seems reasonable to me regarding the KDE Gear plans.

Cheers,
  Albert

> 
> Background:
> kdevelop (qmake plugins) & kdev-php use kdevelop-pg-qt to generate some
> parsing code. The currently released versions of kdevelop-pg-qt have
> Qt5-only code in the deployed utility headers, which are used from the
> generated code (e.g. QString::midRef).
> While kdevelop-pg-qt got prepared for Qt6 already in 2022, the release was
> delayed waiting for the Qt6 ports of the only known consumers kdevelop &
> kdev- php, for some potential synchronization of any Qt6-related changes.
> And by the time it had been forgotten all the released version still only
> are Qt5-only.
> 
> Cheers
> Friedrich

Re: Removing kipi from KDE Gear

[Albert Astals Cid]

El dimarts, 25 de juny del 2024, a les 0:13:38 (CEST), Albert Astals Cid va 
escriure:
> My complaint about the removal of kipi support in gwenview and spectable was
> mostly ignored, so i guess that after two years it's time to remove them
> from KDE Gear.
> 
> I will merge
> https://invent.kde.org/sysadmin/release-tools/-/merge_requests/52 next week
> unless someone strongly disagrees.

This has been merged.

Cheers,
  Albert


> 
> I'm very disappointed on how we removed features from users just because
> their UI looked slightly ugly.
> 
> Saddest of regards,
>   Albert

Re: Remove KNotes from 24.08 release

[Albert Astals Cid]

El dilluns, 15 de juliol del 2024, a les 23:18:29 (CEST), Albert Astals Cid va 
escriure:
> El dilluns, 15 de juliol del 2024, a les 23:14:45 (CEST), Albert Astals Cid
> va
> escriure:
> > Forwarding from
> > https://invent.kde.org/sysadmin/release-tools/-/merge_requests/53
> > 
> > 
> > -
> > 
> > The PIM team has agreed to stop maintaining (and releasing) the KNotes
> > application,
> > 
> > we have a suitable migration path (Marknote has gained support to import
> > notes),
> > 
> > so we want to remove KNotes form 24.08 release and on.
> > 
> > -
> 
> 10 days before the beta seems a bit cutting it close, but ok I guess?

This has been merged.

Cheers,
  Albert

> 
> Cheers,
>   Albert
> 
> > Cheers,
> > 
> >   Albert

kio-gdrive will be removed from KDE Gear master/24.08 in a few days - was - Re: KDE Gear projects with failing CI (master) (11 June 2024)

[Albert Astals Cid]

El dimecres, 12 de juny del 2024, a les 0:13:18 (CEST), Albert Astals Cid va 
escriure:
> Please work on fixing them, otherwise i will remove the failing CI jobs on
> their 4th failing week, it is very important that CI is passing for multiple
> reasons.
> 
> 
> VERY BAD NEWS - massif-visualizer appstream test is still failing after 4
> weeks, I've disabled requiring the tests to pass until it's fixed. It's very
> sad this has not been addressed in a month time.
> 
> 
> 
> VERY BAD NEWS #2 - kio-gdrive Qt 5.15 CI has been unbuildable and has been
> removed from CI. If this doesn't get resolved before the 24.08 release we
> will have to drop kio-gdrive from KDE Gear [*]

There has been no action on this, you have until Sunday when I will create the 
24.08 branches to fix it, if it is not fixed, we will not have kio-gdrive on 
KDE Gear 24.08 since the default build is unbuildable in CI and that's 
unacceptable.

Cheers,
  Albert

> 
> 
> Good news: 3 repositories fixed
> 
> Bad news: *4* repositories keep failing and 2 new repositories started
> failing
> 
> 
> dolphin - 3rd week
>  * https://invent.kde.org/system/dolphin/-/pipelines/711192
>   * craft_windows_qt6_x86_64 fails to compile kio-extras
> 
> 
> ark - 3rd week
>  * https://invent.kde.org/utilities/ark/-/pipelines/711195
>   * kerfuffle-extracttest fails on FreeBSD
> 
> 
> kwalletmanager - 3rd week
>  * https://invent.kde.org/utilities/kwalletmanager/-/pipelines/711196
>   * appstreamtest fails because https://apps.kde.org/kwalletmanager5 doesn't
> exist
> 
> 
> neochat - 3rd week
>  * https://invent.kde.org/network/neochat/-/pipelines/711208
>   Tests fail on Windows
> 
> 
> kdenlive - NEW
>  * https://invent.kde.org/multimedia/kdenlive/-/pipelines/711197
>   * craft_appimage_qt6_x86_64, craft_macos_qt6_arm64 and
> craft_windows_qt6_mingw64 fail
> 
> 
> Cheers,
>   Albert
> 
> 
> [*] One way of resolving it is making kio-gdrive Qt6 only

Re: Remove KNotes from 24.08 release

[Albert Astals Cid]

El dilluns, 15 de juliol del 2024, a les 23:14:45 (CEST), Albert Astals Cid va 
escriure:
> Forwarding from
> https://invent.kde.org/sysadmin/release-tools/-/merge_requests/53
> 
> 
> -
> 
> The PIM team has agreed to stop maintaining (and releasing) the KNotes
> application,
> 
> we have a suitable migration path (Marknote has gained support to import
> notes),
> 
> so we want to remove KNotes form 24.08 release and on.
> 
> -

10 days before the beta seems a bit cutting it close, but ok I guess?

Cheers,
  Albert

> 
> Cheers,
>   Albert

Remove KNotes from 24.08 release

[Albert Astals Cid]

Forwarding from 
https://invent.kde.org/sysadmin/release-tools/-/merge_requests/53


-

The PIM team has agreed to stop maintaining (and releasing) the KNotes 
application,

we have a suitable migration path (Marknote has gained support to import 
notes), 

so we want to remove KNotes form 24.08 release and on.

-


Cheers,
  Albert

Re: Removing kipi from KDE Gear

[Albert Astals Cid]

El dimecres, 26 de juny del 2024, a les 3:59:05 (CEST), Shlomi Fish va 
escriure:
> Hi Albert,
> 
> On Tue, 25 Jun 2024 00:13:38 +0200
> 
> Albert Astals Cid  wrote:
> > My complaint about the removal of kipi support in gwenview and spectable
> > was mostly ignored, so i guess that after two years it's time to remove
> > them from KDE Gear.
> > 
> > I will
> > merge https://invent.kde.org/sysadmin/release-tools/-/merge_requests/52
> > next week unless someone strongly disagrees.
> > 
> > I'm very disappointed on how we removed features from users just because
> > their UI looked slightly ugly.
> 
> For what it is worth, I would like to keep Kipi support in gwenview / etc.

There's nothing to keep it was removed 2 years ago.

Cheers,
  Albert

> 
> Regards,
> 
>   Shlomi Fish
> 
> > Saddest of regards,
> > 
> >   Albert

Removing kipi from KDE Gear

[Albert Astals Cid]

My complaint about the removal of kipi support in gwenview and spectable was 
mostly ignored, so i guess that after two years it's time to remove them from 
KDE Gear.

I will merge https://invent.kde.org/sysadmin/release-tools/-/merge_requests/52 
next week unless someone strongly disagrees.

I'm very disappointed on how we removed features from users just because their 
UI looked slightly ugly.

Saddest of regards,
  Albert

Re: Moving KWeatherCore to Gear

[Albert Astals Cid]

El dilluns, 27 de maig del 2024, a les 17:36:06 (CEST), Volker Krause va 
escriure:
> Hi,
> 
> I'd like to propose adding KWeatherCore [1] to the Gear release automation.
> It's main consumer (KWeather) is already in Gear, so for that alone it makes
> sense IMHO. I'd also like to replace the weather code in Itinerary with
> that eventually, for which synchronized and predictable releases would also
> be helpful.
> 
> I've checked with Devin on #plasma-mobile a couple of days ago, and he'd be
> ok with this.

More than two weeks have passed and no one seems to disagree.

Can you prepare a MR like 
https://invent.kde.org/sysadmin/release-tools/-/merge_requests/50/diffs
?

Thanks,
  Albert

> 
> Thanks,
> Volker
> 
> [1] https://invent.kde.org/libraries/kweathercore

KDE Gear 24.08 Schedule

[Albert Astals Cid]

If no one disagrees i will remove the "NOT OFFICIAL" from the top of
https://community.kde.org/Schedules/KDE_Gear_24.08_Schedule

Cheers,
  Albert

P.S: Little heads up because we had discussed a few months ago already

Re: KDE Gear 24.05.0 packages available for packagers

[Albert Astals Cid]

El divendres, 24 de maig del 2024, a les 15:04:07 (CEST), Christophe Marin va 
escriure:
> Hello,
> 
> On vendredi 17 mai 2024 15:33:49 UTC+2 Heiko Becker wrote:
> > Hello packagers,
> > 
> > tarballs are available at the usual place under
> > "stable/release-service/24.05.0".
> > 
> > Please report any issues, release is planned next Thursday.
> 
> kalgebra installs an unusable plasma applet (plasmoids/graphsplasmoid) :
> 
> can't install kalgebra-24.05.0-1.2.x86_64:
> nothing provides qt6qmlimport(org.kde.plasma.components.2) needed by
> kalgebra-24.05.0.x86_64

Yes, the kalgebra plasmoid has not been ported to Plasma6, this is not a new 
of KDE Gear 24.05 though, as far as I can see was the same in 24.02.

Cheers,
  Albert

> 
> Christophe

Re: KDE Gear 24.05.0 packages available for packagers

[Albert Astals Cid]

El divendres, 17 de maig del 2024, a les 23:13:36 (CEST), Heiko Becker va 
escriure:
> Hello Marc,
> 
> On Friday, 17 May 2024 22:58:03 CEST, Marc Deop i Argemí wrote:
> > did we miss a release for https://invent.kde.org/network/kio-extras ?
> > 
> > There seems to be a 24.04.90: https://invent.kde.org/network/kio-extras/-/
> > tags/v24.04.90
> 
> I'm a bit confused because the tarball for 24.05.0 is clearly there, I just
> double checked.
> 
> Unless you mean kio-extras-kf5, which we don't want to release anymore, at
> least Albert and I, and nobody else has spoken up about it.

To be extra clear, the fact that kio-extras-kf5 is not getting new releases 
doesn't mean distributions should stop shipping it.

Cheers,
  Albert



> 
> Regards,
> Heiko

KDE Gear 24.05 RC release

[Albert Astals Cid]

Packages are available at the usual locations.

Everything compiles fine for me (except kdev-python that doesn't work with 
python 3.12)

Cheers,
  Albert

Re: Moving KGraphViewer & Massif Visualizer to KDE Gear

[Albert Astals Cid]

El dimarts, 16 d’abril del 2024, a les 0:46:55 (CEST), Friedrich W. H. 
Kossebau va escriure:
> Hi,
> 
> I would like to propose moving both KGraphViewer (invent.kde.org/graphics/
> kgraphviewer) & Massif Visualizer (invent.kde.org/sdk/massif-visualizer) to
> the KDE Gear release bundle on next occasion.
> 
> Both are rather stable in their feature-set and "community-maintained".
> As such community maintenance, they just got finally their Qt6 port
> completed and turned Qt6-only in the master branches.
> 
> Ideally the "next occasion" would already be KDE 24.05, if that would be
> still acceptable given the history of the repos.

Added for 24.08 since noone complained in 2 weeks.

Cheers,
  Albert

> 
> While adding more work onto the Gear release managers already now, it would
> save individuals (like myself) from trying to do custom releases work, where
> otherwise the Gear release automation could free some time to e.g. do any
> needed regression finding & fixing.
> 
> Cheers
> Friedrich

KF5 kio-extras and future releases

[Albert Astals Cid]

I have not included a package of the kf5 branch of kio-extras in the KDE Gear 
24.05 release.

At least two people have asked me about whether it should be included or not.

I honestly don't know what to say :D

In my mind it's a no and i'll explain the reasons below, feel free to disagree 
or prove my points nonsense.

As far as I understand kio-extras-kf5 was created because:
 A) We needed a KF6 kio-extras so that KF6 apps can use extra-kio stuff
 B) We needed a KF5 kio-extras that could be coinstalled with the above KF6 
kio-extras so that KF5 apps can use extra-kio stuff

Now, question is should we keep releasing kio-extras-kf5 or not?

Given KF5 kio is in a relatively deep freeze, no new changes in kio-extras-kf5 
are going to be needed to adapt to changes in kio. 

kio-extras-kf5 is extracted from a branch named "kf5" that I guess not many 
developers are really paying attention to because it's neither master nor the 
usual release/xx.yy branch.

It could happen that we need a very important bugfix to kio-extras-kf5 and it 
would be commited to that branch and we would need to do a release.

But given how that doesn't seem super likely and how much of a pain it is to 
our release process to release it (we need to release two tarballs from the 
same repo but from different branches) I would really really say, no,  we 
don't release it with every single KDE Gear release (until we drop KF5 
support), if there's any eventual bugfix we'll just release a new tarball (in 
the 24.02.x naming?).

Cheers,
  Albert

KDE Gear 24.05 Beta release

[Albert Astals Cid]

Packages are available at the usual locations.

krfb does not compile at this point (needs an unreleased kpipewire).

I've contacted the people that should fix it and we're hoping to get it fixed 
ASAP.

Cheers,
  Albert

Re: AppStream Metadata with our releases

[Albert Astals Cid]

El divendres, 22 de març del 2024, a les 0:37:00 (CEST), Julius Künzel va 
escriure:
> Hi!
> 
> (This mail goes to multiple lists, please reply to kde-devel)
> 
> With Flathub beeing more strict on its AppStream metadata guidlines [1]
> there is yet another spotlight on AppStream metadata.
> 
> AppStream metadata are consumed by app stores like Flathub, Snapcraft,
> Discover, our scripts to submit apps to the Microsoft Store and last but
> not least by apps.kde.org [2].
> 
> For release info in particular the quality guidelines say: "Make sure all
> your releases have release notes, even minor ones." [3] As I think this
> makes perfectly sense, I like to propose two things that seem straight
> forward to me:
> 
> - We should not remove older releases from the AppStream data as already
> suggested by Carl in a merge request [4].

I'd go for 
https://invent.kde.org/sysadmin/release-tools/-/merge_requests/48/diffs
instead.

Cheers,
  Albert

> 
> - Also it would be convenient to add noteworthy changes to the metadata
> together with the related code change. However at the moment for KDE Gear
> the release is usually only added to the metadata a few days before
> tagging. Would it be possible to add the next minor release to the release
> branch right after the current one has been released and the next major
> release to master ones the upcoming version has been branched?
> 
> I belive this makes it easier for developers to contribute to the release
> meta info and I hope it hence raises motivation to do so.
> 
> I am happy to hear your opionions, thoughts and concerns!
> 
> Cheers,
> Julius
> 
> [1] https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines
> [2] https://apps.kde.org/
> [3]
> https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/quality-g
> uidelines/#release-notes [4]
> https://invent.kde.org/sysadmin/appstream-metainfo-release-update/-/merge_r
> equests/6
> 
> Julius Künzel
> Volunteer KDE Developer, mainly hacking Kdenlive
> KDE GitLab: www.invent.kde.org/jlskuz https://invent.kde.org/jlskuz
> Matrix: @jlskuz:kde.org https://go.kde.org/matrix/#/@jlskuz:kde.org

Re: KDE Gear: add Kalm

[Albert Astals Cid]

El dimarts, 16 d’abril del 2024, a les 0:56:57 (CEST), Heiko Becker va 
escriure:
> On Sunday, 14 April 2024 23:48:37 CEST, Albert Astals Cid wrote:
> > El dimecres, 27 de març del 2024, a les 9:23:54 (CEST), Plata va escriure:
> >> Generally, I think the reasoning makes sense. However, in the case of
> >> Kalm, I don't think it's required. If you look at the app, it's pretty
> >> simplistic (intentionally, due to its purpose).
> >> 
> >> Therefore, I would prefer to just get it out to the public to
> >> eventually ...
> > 
> > The dependency freeze for KDE Gear 24.05 is this thursday, it
> > would be good if
> > we get some tie breaking comment here so far we have two votes (the person
> > proposing it for yes "obvious, so only gets 0.5 value for yes")
> > and (me voting
> > 0.5 against).
> 
> To be honest, I don't feel very decisive about this one. For me it seems
> even a tad too simple for monthly releases. On the other hand, it doesn't
> have any insane dependencies and is well behaved, so in absence of other
> rules I'll add my +0.1.

Ok, so with your 0.1 the answer, this is a "yes" and I've added it to the 
release.

Cheers,
  Albert

> 
> Regards,
> Heiko

Re: Moving KUnifiedPush to KDE Gear

[Albert Astals Cid]

El dilluns, 15 d’abril del 2024, a les 18:06:30 (CEST), Volker Krause va 
escriure:
> Hi,
> 
> I'd like to propose the KUnifiedPush library
> (https://invent.kde.org/libraries/ kunifiedpush) for inclusion in KDE Gear.

My answer when someone else asked the same question for other apps on Matrix 
this morning.

I'd say feels a bit late with dependency freeze in 3 days and freeze freeze in 
10.

I'd prefer 2 weeks before dependency freeze, could live with 2 weeks before 
freeze freeze. [1] 

Can we wait for 24.08 for this?

Cheers,
  Albert

[1] This is to give people enough time to say yes/no/question things.

> 
> This was stalled for some time but we finally have a default server
> installation thanks to Carl, so this is now actually useful for people not
> running their own infrastructure as well.
> 
> There's two users of this already, Neochat and Tokodon, both have it as an
> optional dependency at the moment.
> 
> Thanks,
> Volker

Re: KDE Gear: add Kalm

[Albert Astals Cid]

El dimecres, 27 de març del 2024, a les 9:23:54 (CEST), Plata va escriure:
> Thanks for the feedback!
> 
> 
> Generally, I think the reasoning makes sense. However, in the case of
> Kalm, I don't think it's required. If you look at the app, it's pretty
> simplistic (intentionally, due to its purpose).
> 
> Therefore, I would prefer to just get it out to the public to eventually
> get some feedback. I think it's pretty unlikely that anybody will notice
> it if I just create a release myself.

The dependency freeze for KDE Gear 24.05 is this thursday, it would be good if 
we get some tie breaking comment here so far we have two votes (the person 
proposing it for yes "obvious, so only gets 0.5 value for yes") and (me voting 
0.5 against).

Cheers,
  Albert

> 
> > El dilluns, 25 de març de 2024, a les 8:10:43 (CET), Plata va escriure:
> >> Dear Release Team,
> >> 
> >> 
> >> Kalm has spent some time in KDE Review (see
> >> https://invent.kde.org/utilities/kalm/-/issues/2). Can we add it
> >> to/release it in KDE Gear?
> > 
> > As far as I understand Kalm has never been released, right?
> > 
> > For new apps *personally* I always suggest to do a few releases on your
> > own
> > because it allows for much faster feature turn-around than KDE Gear that
> > has a very strict 3 months for new features schedule, that is usually
> > fine for "established" apps but for something new you may very well find
> > that there's that obvious feature missing that everyone needs and now you
> > can't add it until 3 months in the future.
> > 
> > Cheers,
> > 
> >Albert
> >> 
> >> Best regards
> >> 
> >> Plata
> >> 
> >> P.S.: CC me on the answers, I'm not subscribed

Re: KDE Gear: add Kalm

[Albert Astals Cid]

El dilluns, 25 de març de 2024, a les 8:10:43 (CET), Plata va escriure:
> Dear Release Team,
> 
> 
> Kalm has spent some time in KDE Review (see
> https://invent.kde.org/utilities/kalm/-/issues/2). Can we add it
> to/release it in KDE Gear?

As far as I understand Kalm has never been released, right?

For new apps *personally* I always suggest to do a few releases on your own 
because it allows for much faster feature turn-around than KDE Gear that has a 
very strict 3 months for new features schedule, that is usually fine for 
"established" apps but for something new you may very well find that there's 
that obvious feature missing that everyone needs and now you can't add it 
until 3 months in the future.

Cheers,
  Albert

 
> 
> Best regards
> 
> Plata
> 
> P.S.: CC me on the answers, I'm not subscribed

Re: Dependency freeze exception for kdepim-runtime

[Albert Astals Cid]

El dimarts, 12 de març de 2024, a les 12:50:53 (CET), Carl Schwan va escriure:
> Hi,
> 
> I fixed the compilation issue in kdepim-runtime for the optional etesync
> feature. I would like to backport this to the release/24.02 branch, but this
> bring back the QtConcurrent dependency which I suppose was implicitly
> pulled in the qt5 time.


This is not a new dependency, QtConcurrent is part of QtBase and this 
application already depends on QtBase.

Cheers,
  Albert

> 
> This is the commit in question:
> https://invent.kde.org/pim/kdepim-runtime/-/commit/
> 65edf9bbf56de4a58bbfbe833cb546617c54a201
> 
> Cheers,
> Carl

Re: Move Accessibility inspector to release service/gear

[Albert Astals Cid]

El dimecres, 21 de febrer de 2024, a les 0:01:59 (CET), Carl Schwan va 
escriure:
> Hi,
> 
> me again :) I would like to move the accessibility inspector which is now a
> standalone app to Gear. This apps was always part of gear but albeit as a
> non- installed binary in the libqaccessibilityclient repository. This is
> now a standalone repo and it received significant work in the past months.
> 
> I'm planning to release a 1.0 as soon as kf6 is release and afterward it
> would be great to have it back in the release service.

No disagreements in 2 weeks, so let's go for it.

Please make sure this gets an auto-updating version number.

Cheers,
  Albert


> 
> Cheers,
> Carl

Re: Move Francis to the release service/gear

[Albert Astals Cid]

El dimarts, 20 de febrer de 2024, a les 23:58:49 (CET), Carl Schwan va 
escriure:
> Hi,
> 
> me again, I would like to move Francis to KDE Gear. It got a first release
> not long ago and was ported to kf6. While the app feature wise is mostly
> feature- compleate, I think regular updates for small features and
> bugfixing and translations are important.
> 
> https://invent.kde.org/utilities/francis/

No disagreements in 2 weeks, so let's go for it.

Please make sure this gets an auto-updating version number.

Cheers,
  Albert

> 
> Cheers,
> Carl

Re: Move Audex to release service/gear

[Albert Astals Cid]

El dimarts, 20 de febrer de 2024, a les 23:55:11 (CET), Carl Schwan va 
escriure:
> Hi,
> 
> I would like to move Audex to the release service. It didn't had any release
> since kde4 but was ported to kf5 and now to kf6 too. It would be good to
> have more consistent release.
> 
> I asked the maintainer and he agreed:
> https://invent.kde.org/multimedia/audex/-/issues/3

No disagreements in 2 weeks, so let's go for it.

Please make sure this gets an auto-updating version number.

And i agree with Jonathan that a bit nicer description won't hurt.

Cheers,
  Albert

> 
> Cheers,
> Carl

Re: Changed KAlarm dependency for KDE Gear 24.02.1

[Albert Astals Cid]

El dissabte, 2 de març de 2024, a les 18:55:35 (CET), David Jarvie va 
escriure:
> A significant bug fix has been made for KAlarm to fix long standing audio
> issues. Following a recommendation by Harald Sitter, I've replaced the use
> of Phonon with libcanberra for playing sounds. This is now in master branch
> (https://invent.kde.org/pim/
> kalarm/-/commit/dd4bab1a3642c0ec860ffada450d4d41dd85080f[1] and https://
> invent.kde.org/pim/kalarm/-/commit/63fe942beb2d2b72c4b955beea955ffb23ef0d71
> [2]), but I'd like to include the fix in KDE Gear 24.02.1. Given that this
> requires a dependency change, can I go ahead with this?

It's highly inusual to change dependencies in the middle of a release.

But if that bug is high impact and given that we already require libcanberra 
in other software so folks possibly already have it available i don't think 
it's a terrible change.

Cheers,
  Albert

P.S: Other thing to ask is whether libcanberra not having had a release in 12 
years makes it a good depencency to have, but that's for another day.

Re: Warehouse keeper game Skladnik into KDE Gear (for 24.05)

[Albert Astals Cid]

El divendres, 23 de febrer de 2024, a les 0:29:14 (CET), Albert Astals Cid va 
escriure:
> El divendres, 16 de febrer de 2024, a les 21:47:10 (CET), Heiko Becker va
> 
> escriure:
> > On Monday, 12 February 2024 18:23:15 CET, Friedrich W. H. Kossebau wrote:
> > > I propose to move Skladnik to KDE Gear for 24.05 to rejoin the set of
> > > KDE
> > > games again, which it already was part of in KDE 1-3 times (by the name
> > > KSokoban).
> > > 
> > > It just passed kde(re)review, and before has seen recent releases, by
> > > some
> > > 0.5.0 last year, and this year some translations update 0,5,1.
> > > It also has just turned Qt6/KF6-only and will see a 0.5.2 release with
> > > that
> > > right after Mega6 (planning for Feb. 29th).
> > > 
> > > Prepared respective MRs:
> > > https://invent.kde.org/sysadmin/release-tools/-/merge_requests/47/diffs
> > 
> > To avoid confirmation by missing objections: I'm in favour of Skladnik
> > joining Gear.
> 
> My silent approval reminder was set on the 26, but i guess we can add it
> already :)

Forgot to say, please make sure the version number is auto incrementing.

Cheers,
  Albert

> 
> Cheers,
>   Albert
> 
> > Regards,
> > Heiko

Re: Warehouse keeper game Skladnik into KDE Gear (for 24.05)

[Albert Astals Cid]

El divendres, 16 de febrer de 2024, a les 21:47:10 (CET), Heiko Becker va 
escriure:
> On Monday, 12 February 2024 18:23:15 CET, Friedrich W. H. Kossebau wrote:
> > I propose to move Skladnik to KDE Gear for 24.05 to rejoin the set of KDE
> > games again, which it already was part of in KDE 1-3 times (by the name
> > KSokoban).
> > 
> > It just passed kde(re)review, and before has seen recent releases, by some
> > 0.5.0 last year, and this year some translations update 0,5,1.
> > It also has just turned Qt6/KF6-only and will see a 0.5.2 release with
> > that
> > right after Mega6 (planning for Feb. 29th).
> > 
> > Prepared respective MRs:
> > https://invent.kde.org/sysadmin/release-tools/-/merge_requests/47/diffs
> 
> To avoid confirmation by missing objections: I'm in favour of Skladnik
> joining Gear.

My silent approval reminder was set on the 26, but i guess we can add it 
already :)

Cheers,
  Albert

> 
> Regards,
> Heiko

Re: KDE Gear 24.02 bug fix releases and next Gear releases

[Albert Astals Cid]

El divendres, 16 de febrer de 2024, a les 21:40:33 (CET), Heiko Becker va 
escriure:
> On Tuesday, 30 January 2024 23:39:43 CET, Albert Astals Cid wrote:
> > El dijous, 21 de desembre de 2023, a les 19:49:42 (CET), Heiko Becker va
> > 
> > escriure:
> >> On Tuesday, 28 November 2023 16:21:38 CET, Albert Astals Cid wrote: ...
> > 
> > No one complained much so
> > 
> > https://community.kde.org/Schedules/KDE_Gear_24.02_Schedule
> > https://community.kde.org/Schedules/KDE_Gear_24.05_Schedule
> > https://community.kde.org/Schedules/KDE_Gear_24.08_Schedule
> > 
> > How does that sound?
> 
> Works for me.
> One thing I noticed is that 24.05.0 is planned to happen at the same day as
> Plasma 6.0.90 (at least according to
> https://community.kde.org/Schedules/Plasma_6) though.

I'd say that's probably fine?

What's everyone's opinon?

Cheers,
  Albert

KDE Gear 24.02 RC 2 packages available

[Albert Astals Cid]

Please everyone wait for the actual "Mega release" announcement before 
starting to make noise, but you can start compiling things.

https://community.kde.org/KDE_Gear/24.02_Release_notes

https://kde.org/info/releases-24.01.95

https://kde.org/announcements/changelogs/gear/24.01.95/

Cheers,
  Albert

Re: KDE Gear 24.02 bug fix releases and next Gear releases

[Albert Astals Cid]

El dijous, 21 de desembre de 2023, a les 19:49:42 (CET), Heiko Becker va 
escriure:
> On Tuesday, 28 November 2023 16:21:38 CET, Albert Astals Cid wrote:
> > I think b) isn't the best idea, I think the .4/.8/.12 schedule
> > has worked well
> > for us for a long time, we only exceptionally decided to shift it for this
> > release because it was better to ship most of our things
> > together because of
> > the Qt6 migration.
> > 
> > Personally in my brain I had the a) scenario, but you are right that
> > having
> > 24.04 just after 24.02 may not be the best time wise (and
> > waiting for 24.08 is
> > also too much), so I have now been convinced that c) may be a
> > get idea, so we
> > get back to our "usual" release schedule a bit more "slowly"
> > 
> > That would leave us with:
> >   24.02.0: February
> >   24.02.1: March
> >   24.02.2: April
> >   24.05.0: May
> >   24.05.1: June
> >   24.05.2: July
> >   24.08.0: August
> > 
> > ... resume usual scheduling ...
> 
> I like the plan above.

No one complained much so

https://community.kde.org/Schedules/KDE_Gear_24.02_Schedule
https://community.kde.org/Schedules/KDE_Gear_24.05_Schedule
https://community.kde.org/Schedules/KDE_Gear_24.08_Schedule

How does that sound?

> 
> Regards,
> Heiko

Re: Report of packaging issues with mega release - Qt5/6 translation conflicts

[Albert Astals Cid]

El divendres, 26 de gener de 2024, a les 8:53:03 (CET), Fabian Vogt va 
escriure:
> Hi,
> 
> Am Donnerstag, 25. Januar 2024, 22:18:47 CET schrieb Albert Astals Cid:
> > El dissabte, 20 de gener de 2024, a les 17:39:15 (CET), Fabian Vogt va
> > 
> > escriure:
> > > Hi,
> > > 
> > > Am Freitag, 8. Dezember 2023, 12:56:09 CET schrieb Jonathan Riddell:
> > > > On Fri, 8 Dec 2023 at 10:53, Antonio Rojas  
wrote:
> > > > > > - phonon: Qt5/6 versions collide (translations)
> > > > > > 
> > > > > > For Phonon and similar cases the translations are shared, why not
> > > > > > just
> > > > > 
> > > > > package the translations with one of them which you know to be
> > > > > installed?
> > > 
> > > Is this actually valid?
> > 
> > I ran lrelease from Qt5 and Qt6 over the same phonon libphonon_qt.po and
> > they generated exactly bit by bit the same file.
> > 
> > Is that not your experience?
> 
> That's also what I get from looking at the code.
> 
> > > I don't expect that Qt 5 will always be able to read
> > > QM files produced for Qt 6. The other way around is probably not
> > > guaranteed
> > > either.
> > 
> > Whether there's a promise or not that this will forever be the same, can't
> > say.
> 
> That's the main issue. If Qt 6 gets updated and this is no longer true,

to be honest i'm leaning towards the "it's fine as it is, the potential it may 
break with future Qt6 is probably not going to happen and if it happens we can 
fix it then"

IMHO We have enough work and things that actually fail right now to worry 
about things that may fail in the future.

Cheers,
  Albert

> several packages would have to be changed to separate Qt5/Qt6 translations,
> both in the upstream projects as well as downstream packaging.
> 
> If we assume that Qt 6 will always be able to read Qt 5 QM files, then
> it needs to be documented that translations from a Qt 5 build must be used.
> A Qt 6 "make install" would install the Qt 6 QM files and break the Qt 5
> lib.
> 
> To avoid ^ or to be on the safe side, translations need to be versioned to
> avoid collisions.
> 
> Cheers,
> Fabian
> 
> > Cheers,
> > 
> >   Albert
> >   
> > > IMO the translations need to contain the Qt version in their path name,
> > > either filename or somewhere in the installation path.
> > > 
> > > This is also an issue for e.g. kimageannotator:
> > > https://invent.kde.org/graphics/gwenview/-/merge_requests/245#note_85173
> > > 0
> > > 
> > > Cheers,
> > > Fabian
> > > 
> > > > > > Jonathan
> > > > > 
> > > > > Because none of them is guaranteed to be installed. Only the one
> > > > > that is
> > > > > pulled as a dependency of something will
> > > > 
> > > > Can you put them in a common package that both libraries depend on?
> > > > 
> > > > Having two translations for the same repo with the same strings would
> > > > likely cause more effort for translators.
> > > > 
> > > > Jonathan

Re: Report of packaging issues with mega release - Qt5/6 translation conflicts

[Albert Astals Cid]

El dissabte, 20 de gener de 2024, a les 17:39:15 (CET), Fabian Vogt va 
escriure:
> Hi,
> 
> Am Freitag, 8. Dezember 2023, 12:56:09 CET schrieb Jonathan Riddell:
> > On Fri, 8 Dec 2023 at 10:53, Antonio Rojas  wrote:
> > > > - phonon: Qt5/6 versions collide (translations)
> > > > 
> > > > For Phonon and similar cases the translations are shared, why not just
> > > 
> > > package the translations with one of them which you know to be
> > > installed?
> 
> Is this actually valid? 

I ran lrelease from Qt5 and Qt6 over the same phonon libphonon_qt.po and they 
generated exactly bit by bit the same file.

Is that not your experience?

> I don't expect that Qt 5 will always be able to read
> QM files produced for Qt 6. The other way around is probably not guaranteed
> either.

Whether there's a promise or not that this will forever be the same, can't 
say.

Cheers,
  Albert

> 
> IMO the translations need to contain the Qt version in their path name,
> either filename or somewhere in the installation path.
> 
> This is also an issue for e.g. kimageannotator:
> https://invent.kde.org/graphics/gwenview/-/merge_requests/245#note_851730
> 
> Cheers,
> Fabian
> 
> > > > Jonathan
> > > 
> > > Because none of them is guaranteed to be installed. Only the one that is
> > > pulled as a dependency of something will
> > 
> > Can you put them in a common package that both libraries depend on?
> > 
> > Having two translations for the same repo with the same strings would
> > likely cause more effort for translators.
> > 
> > Jonathan

Re: Gear: how to handle the i18n branches/stable/l10n-kf5 branch? (23.08 or 24.02)

[Albert Astals Cid]

El dimecres, 10 de gener de 2024, a les 22:13:34 (CET), Luigi Toscano va 
escriure:
> Hi all,
> 
> the last release of Gear 23.08 (23.08.5) is planned at the beginning of
> February. On the other hand, we need to create the stable branches for
> Gear, which means pointing the branches/stable/l10n-kf5 branch now and have
> it point to the bits of Gear which are still KF5-based.
> 
> I see 3 possible outcome:
> 
> - drop scripty tracking for those branches, release 23.08.5 with whatever we
> have now in branches/stable/l10n-kf5, and start using
> branches/stable/l10n-kf5 for the remaining of KF5 Gear modules. It is less
> than a month and I don't see us losing much;
> 
> - create a special branch to track 23.08.5;
> 
> - restrict 23.08.5 to just the modules which are ported to KF6 in 24.02.
> This way we could use branches/stable/l10n-kf5 to track all remaining KF5
> modules: the ones still in 24.04 and the other still at 23.08.

Personally I prefer "option 4":

* trunk-kf5 tracks KDE Gear 24.02 until 23.08.5 is released
* stable-kf5 tracks KDE Gear until 23.08.5 is released

After that we switch back trunk-kf5  to track KDE Gear master and stable-kf5  
to KDE Gear 24.02

The only downside I see in this option is that KDE Gear master is not tracked 
for a while, but that should not be a problem at all.

Cheers,
  Albert

> 
> Unfortunately we need to decide before tomorrow, January 11th...
> 
> Ciao

KDE Gear 24.02 RC 1 packages available

[Albert Astals Cid]

Please everyone wait for the actual "Mega release" announcement before 
starting to make noise, but you can start compiling things.

https://community.kde.org/KDE_Gear/24.02_Release_notes

https://kde.org/info/releases-24.01.90

Cheers,
  Albert

Re: Branching KDE Gear. When?

[Albert Astals Cid]

El dimarts, 2 de gener de 2024, a les 15:59:03 (CET), Albert Astals Cid va 
escriure:
> We have two options:
> 
>  * Do it before RC1
>  * Do it after RC1
> 
> Doing it before RC1 has the benefit that we start testing things that may
> break because of the new branch existing (CI, translations, etc).
> 
> But since some of those will actually break we should do it relatively
> before the release that is on the 10th of January, so i'd vote this Friday
> the latest.
> 
> Doing it before the RC1 has the issue that we allow Qt6 porting up to RC1
> and Qt6 porting is usually quite big and one would not want to have to mess
> with branches when doing big changes.
> 
> Given that we have a RC2, i'd personally vote for branching [just] after
> RC1.
> 
> What do you all think?

Since no one gave a vote for do it on Friday, and it's Friday already, let's 
do the branching after RC1.

Cheers,
  Albert

> 
> Cheers,
>   Albert

Branching KDE Gear. When?

[Albert Astals Cid]

We have two options:

 * Do it before RC1
 * Do it after RC1

Doing it before RC1 has the benefit that we start testing things that may 
break because of the new branch existing (CI, translations, etc).

But since some of those will actually break we should do it relatively before 
the release that is on the 10th of January, so i'd vote this Friday the 
latest.

Doing it before the RC1 has the issue that we allow Qt6 porting up to RC1 and 
Qt6 porting is usually quite big and one would not want to have to mess with 
branches when doing big changes.

Given that we have a RC2, i'd personally vote for branching [just] after RC1.

What do you all think?

Cheers,
  Albert

Re: Thoughts on KDE Gear 23.08.5?

[Albert Astals Cid]

El dijous, 7 de desembre de 2023, a les 19:30:58 (CET), Heiko Becker va 
escriure:
> Hi,
> 
> obviously it's hard to predict the future and to foresee the need for an
> important fix, but assuming there isn't any big issue, is there a general
> need for an 23.08.5 release (some time in January)?
> 
> From .2 to .4 we've gone from 126 to 106 to 68 commits in the (sanitized)
> changelog for 36, 35 and 37 projects.

We're still 11 weeks away from 24.02, we usually would even have 2 releases in 
that time :D

Personally I think given how "far" away that is and looking at 
  https://kde.org/announcements/changelogs/gear/23.08.4/
that having a .5 would be good (assuming it's not a lot of work for us/you).

Should we do it around mid February? Week of 12-16?

Cheers,
  Albert

> 
> Cheers,
> Heiko

KDE Gear 24.02 Beta 1 packages available

[Albert Astals Cid]

Please everyone wait for the actual "Mega release" announcement before 
starting to make noise, but you can start compiling things.

I am sitting at Thiago's talk in Qt World Summit so I have not had time to 
compile them, hope most things are good :crossesfingers:

https://community.kde.org/KDE_Gear/24.02_Release_notes

https://kde.org/info/releases-24.01.80

Cheers,
  Albert

Re: KDE Gear 24.02 bug fix releases and next Gear releases

[Albert Astals Cid]

El dilluns, 27 de novembre de 2023, a les 8:57:26 (CET), Heiko Becker va 
escriure:
> Hi everyone,
> 
> the question of the next Gear release (after 24.02) came up in #kde-devel
> yesterday evening. Due to this, it also occured to me that we haven't
> scheduled any bug fix releases for 24.02 itself. Which is a bit connected
> to the first question, because I guess we don't want too many stable
> branches at the same time (as in more than 1 really).
> 
> I mostly see three options, but of course please chime if you think of
> something else:
> 
> 
> a) Continue with the usual dates, eg. 24.04 and 24.08. (or omitting 24.04
> and continue with 24.08 right away)
> 
> b) Continue with the usual interval, so 24.06, 24.10 and so on
> 
> c) Slightly change the interval to come back to the proven schedule with
> its nice numbers divisible by 4, so something like, 24.05 and 24.08.
> 
> 
> Personally, I'd favour b) or c). I think a) is either too short or too
> long. Not sure how b) would interact with holiday schedules, exams or
> distro releases though.

I think b) isn't the best idea, I think the .4/.8/.12 schedule has worked well 
for us for a long time, we only exceptionally decided to shift it for this 
release because it was better to ship most of our things together because of 
the Qt6 migration.

Personally in my brain I had the a) scenario, but you are right that having 
24.04 just after 24.02 may not be the best time wise (and waiting for 24.08 is 
also too much), so I have now been convinced that c) may be a get idea, so we 
get back to our "usual" release schedule a bit more "slowly"

That would leave us with:
  24.02.0: February
  24.02.1: March
  24.02.2: April
  24.05.0: May
  24.05.1: June  
  24.05.2: July
  24.08.0: August
... resume usual scheduling ...

Cheers,
  Albert

> 
> Regards,
> Heiko

Re: KDE Gear 24.02 bug fix releases and next Gear releases

[Albert Astals Cid]

El dilluns, 27 de novembre de 2023, a les 19:16:27 (CET), Laura David Hurka va 
escriure:
> > On Monday, 2023-09-04T05:50:45z David Edmundson wrote:
> > > [...] The KDE Gear release will move by 2 months [...]
> 
> I think now I get the confusion:
> Does this sentence refer to “KDE Gear 23.12” or to the general “KDE Gear
> release schedule”?
> 
> I just assumed only 23.12 is delayed, because there was once a discussion
> about changing the schedule in general, and it was thought to be fine as it
> is.

Yes, that 2 months shift was discussed as a one time thing, not as a forever 
thing.

Cheers,
  Albert

Re: KDE Gear 23.02 branching

[Albert Astals Cid]

El dimarts, 7 de novembre de 2023, a les 0:43:40 (CET), Albert Astals Cid va 
escriure:
> We usually branch before Beta, but given how long this cycle is would anyone
> mind if we branched later, say a bit before RC1?
> 
> It means that there's like a month that no new features can be added to
> master in Gear, can we live with that?

No one has disagreed so we will do that.

Cheers,
  Albert

> 
> Cheers,
>   Albert

Re: KDE Frameworks 5.112.0

[Albert Astals Cid]

El diumenge, 12 de novembre de 2023, a les 10:00:30 (CET), David Faure va 
escriure:
> On lundi 6 novembre 2023 23:16:54 CET David Faure wrote:
> > On lundi 6 novembre 2023 21:46:51 CET Albert Astals Cid wrote:
> > > Can you respin karchive to include my last commit in the kf5 branch?
> > > https://invent.kde.org/frameworks/karchive/-/commits/kf5
> > 
> > Hmm, there is very likely more code affected by this shared-mime-info
> > change:
> > [...]
> > Hopefully we can sort this out quick and
> > release a new shared-mime-info before too many people use 2.3
> 
> I just made a 2.4 release of shared-mime-info to repair this.
> 
> https://gitlab.freedesktop.org/xdg/shared-mime-info/-/releases/2.4

Awesome :)

Cheers,
  Albert

Re: KDE Gear 24.02 Alpha packages available

[Albert Astals Cid]

El dijous, 9 de novembre de 2023, a les 7:46:34 (CET), Eric Hameleers va 
escriure:
> On Wed, 8 Nov 2023, Albert Astals Cid wrote:
> > Please everyone wait for the actual "Mega release" announcement before
> > starting to make noise, but you can start compiling things.
> > 
> > I have not had time to compile them locally but CI says things should
> > mostly build.
> > 
> > https://community.kde.org/KDE_Gear/24.02_Release_notes
> > 
> > https://kde.org/info/sources/source-releases-24.01.75.html
> > 
> > Cheers,
> > 
> >  Albert
> > 
> > P.S: https://kde.org/info/releases-24.01.75 should have been created but
> > it
> > wasn't and I don't know why ^_^
> 
> Hi,
> 
> Kleopatra looks for MimeTreeParser and fails to build without it.
> However, MimeTreeParser was not part of the Alpha release. Can a
> tarball for mimetreeparser be created please?

Done.

Cheers,
  Albert

> 
> Cheers, Eric

[sysadmin/release-tools] /: Add mimetreeparser to release service

[Albert Astals Cid]

Git commit 3bb05850e9ea481eaf8715f0e27ca9458338b47b by Albert Astals Cid.
Committed on 09/11/2023 at 19:22.
Pushed by aacid into branch 'master'.

Add mimetreeparser to release service

Assuming that we don't need review nor agreement since it's a spinoff
(and a dependency) of existing release service apps

CCMAIL: release-team@kde.org

M  +1-0modules.git

https://invent.kde.org/sysadmin/release-tools/-/commit/3bb05850e9ea481eaf8715f0e27ca9458338b47b

diff --git a/modules.git b/modules.git
index aed3476..edb05f8 100644
--- a/modules.git
+++ b/modules.git
@@ -242,3 +242,4 @@ plasmatube  master
 arianna master
 isoimagewriter  master
 khealthcertificate  master
+mimetreeparser  master

KDE Gear 24.02 Alpha packages available

[Albert Astals Cid]

Please everyone wait for the actual "Mega release" announcement before 
starting to make noise, but you can start compiling things.

I have not had time to compile them locally but CI says things should mostly 
build.

https://community.kde.org/KDE_Gear/24.02_Release_notes

https://kde.org/info/sources/source-releases-24.01.75.html

Cheers,
  Albert

P.S: https://kde.org/info/releases-24.01.75 should have been created but it 
wasn't and I don't know why ^_^

KDE Gear 23.02 branching

[Albert Astals Cid]

We usually branch before Beta, but given how long this cycle is would anyone 
mind if we branched later, say a bit before RC1?

It means that there's like a month that no new features can be added to master 
in Gear, can we live with that?

Cheers,
  Albert

Re: KDE Frameworks 5.112.0

[Albert Astals Cid]

El dissabte, 4 de novembre de 2023, a les 12:29:12 (CET), David Faure va 
escriure:
> Dear packagers,
> 
> KDE Frameworks 5.112.0 has been uploaded to the usual place.
> 
> New frameworks: none this time.
> 
> Public release next Saturday.
> 
> Thanks for the packaging work!

Can you respin karchive to include my last commit in the kf5 branch?

https://invent.kde.org/frameworks/karchive/-/commits/kf5

Cheers,
  Albert

Time of the releases

[Albert Astals Cid]

I didn't write a time for the releases when writing 
  https://community.kde.org/Schedules/February_2024_MegaRelease
on purpose.

I understand we don't need to *exactly* time the tarballs, just make them 
happen during the same day.

So for Alpha this Wednesday we will publish the tarballs at some point during 
Wednesday and email the list about it.

Is that right? Or do you think we should do it differently?

Cheers,
  Albert 

Re: KDE Gear Qt 5 deps

[Albert Astals Cid]

El divendres, 3 de novembre de 2023, a les 12:25:12 (CET), Jonathan Riddell va 
escriure:
> On Thu, 2 Nov 2023 at 21:11, Albert Astals Cid  wrote:
> > libkcddb seems like it compiles with qt5 and qt6 so why do we need to make
> > extra releases?
> > 
> > For libkgapi i don't have enough domain knowledge, but can't distros just
> > keep
> > build the old tarball with qt5 and the new on with qt6?
> 
> Yes we can also just tell distros to build it twice and they will pick
> their own source package name for the different builds.  If that's what we
> want them to do we should release note it.  Is there a release notes page
> yet for Gear?

https://community.kde.org/KDE_Gear/24.02_Release_notes

> 
> Jonathan

Re: print-manager and wacomtablet to Plasma

[Albert Astals Cid]

El dimecres, 1 de novembre de 2023, a les 1:10:55 (CET), Nate Graham va 
escriure:
> On 10/31/23 17:28, Nicolas Fella wrote:
> > On 10/31/23 23:23, Albert Astals Cid wrote:
> >> El dimarts, 31 d’octubre de 2023, a les 20:43:47 (CET), Jonathan
> >> Riddell va
> >> 
> >> escriure:
> >>> As discuccsed in Plasma meeting and just now with KDE gear release
> >>> spods,
> >>> Plasma would like to take over releases of print-manager and
> >>> wacomtablet.
> >>> This means renumbering the tars from e.g. 23.08 to 5.80.0.
> >>> 
> >>> Any issues?
> >> 
> >> What's the rationale for such move?
> > 
> > See https://mail.kde.org/pipermail/release-team/2023-June/013081.html
> > where I originally brought up the topic
> > 
> > partly it's not relevant any more since we settled on releasing Plasma
> > and Gear together this time. The point about these being effectively
> > tied to Plasma still stands, and as such releasing them together makes
> > sense, for example because it makes it easier to deal with changes in
> > their interaction with Plasma
> 
> Yes, the idea is to move into Plasma the things that really only make
> sense to use *in* Plasma. 

It's true that print-manager is mainly a plasmoid/kded/kcm so if Plasma folks 
want to adopt it, I'm not against it, please propose a MR like 
https://invent.kde.org/sysadmin/release-tools/-/merge_requests/39/diffs
(but in reverse)

> Having such software follow the Plasma release
> schedule prevents the problem of unsynchronized changes due to differing
> release schedules, which bit us multiple times during the Plasma 5 cycle.

That's not a good reason, Plasma developers need to remember that there's 
third party applications out there that may also want to tightly integrate 
with Plasma, so any breaking change that may affect print-manager or whatever 
other non-shipped-by-Plasma software should not be happening.

Cheers,
  Albert

> 
> Nate

Re: isoimagewriter in KDE Gear

[Albert Astals Cid]

El dimarts, 31 d’octubre de 2023, a les 20:42:09 (CET), Jonathan Riddell va 
escriure:
> I'd like to propose releasing isoimagewriter as part of KDE Gear starting
> with the megarelease.  Any issues?

Please create a MR like 
https://invent.kde.org/sysadmin/release-tools/-/merge_requests/39/diffs

If noone disagrees before the alpha we can go ahead and merge it.

Cheers,
  Albert

> 
> Jonathan

Re: KDE Gear Qt 5 deps

[Albert Astals Cid]

El dimecres, 1 de novembre de 2023, a les 11:56:37 (CET), Jonathan Riddell va 
escriure:
> There's a couple libraries that distros need to build both Qt 5 and Qt 6
> versions of because they have apps which use both.
> 
> libkgapi still needs a Qt 5 version for kio-gdrive and a Qt 6 version for
> pim bits.
> 
> libkcddb needs a Qt 5 version for k3b and a Qt 6 version for kio-audiocd.
> 
> So I propose to make standalone releases of the Qt 5 versions using the
> names libkgapi5 and libkcddb5 which distros can pick once when they move
> their packaging to Qt 6 bits.
> 
> How does that sound? 

libkcddb seems like it compiles with qt5 and qt6 so why do we need to make 
extra releases?

For libkgapi i don't have enough domain knowledge, but can't distros just keep 
build the old tarball with qt5 and the new on with qt6?

Cheers,
  Albert

> Are there any more such cases?
> 
> Jonathan

Re: KDE 6 MegaRelease further dependencies

[Albert Astals Cid]

El dimecres, 1 de novembre de 2023, a les 18:55:43 (CET), Jonathan Riddell va 
escriure:
> Me and Justin suggested a Matrix room to coordinate this but nobody seemed
> interested, let me know if you'd like one.

chat rooms are particularly not great to coordinate with people that have 
different availability times, a mailing list or an issue tracker are much 
better for that.

> I'd like to make a Todo board of this somehow, what's the best way to do
> that?

As I mentioned we can just use the issue tracker of the release-service team 
(please can anyone not part of the team confirm if they can open issues there 
i'm unsure how teams work on gitlab?)

Cheers,
  Albert


> 
> Paul made one for Promo https://phabricator.kde.org/T16977
> 
> Further dependencies that Justin pointed me to from Fedora chat
> https://pagure.io/fedora-kde/SIG/issue/383#comment-878191
> 
> = xdg-utils
> External project part of Freedesktop
> Latest release 2018 by
> Current development happening by e.g. Meven and Harald for KF6 support
> https://cgit.freedesktop.org/xdg/xdg-utils/
> Not much activity on the mailing list called Portland (gosh I think I
> remember that name being brought up)
> https://lists.freedesktop.org/archives/portland/
> I don't know who has authority to make a release
> 
> = libaccounts-qt
> External project
> https://gitlab.com/accounts-sso/libaccounts-qt/
> Last release 4 years ago
> Git master builds for both Qt 5 and 6 thanks to Nico
> No activity on the mailing list, it's not clear who can make a release of
> this https://groups.google.com/g/accounts-sso-devel
> 
> = gpgme
> This is fine, current release builds for Qt 5 and 6, just remind distros to
> package newest version
> 
> = qca
> Builds for Qt 5 and 6 for the last couple of releases, just remind distros
> to package newest version
> 
> = packagekit-qt
> Current release builds for Qt 5 and 6, just remind distros to package
> newest version
> 
> = grantlee
> This is now KTextTemplate and part of Frameworks so just release note that
> 
> = signond
> This seems to build for Qt 5 and 6 with no modifications so just release
> note for distos to package it
> 
> = signon-ui
> I have no idea what's going on here, there were releases with ubunntu in
> the version number in 2015 of something called "signon-ui"
> https://gitlab.com/accounts-sso/signon-ui/-/tags
> Now the project is called "signon-ui-qt" in gitlab at least and Nico is
> going work on it so maybe it needs a release? We built it for Qt 5 in neon
> and nobody has complained thus far.
> 
> = signon-plugin-oauth2
> Another one where it's not clear how releases are managed if at all
> https://gitlab.com/accounts-sso/signon-plugin-oauth2/-/tags
> Release 2 years ago uses Qt 5
> No development since then, does it need work for Qt 6?
> 
> = appstream
> Not to be confused with the Amazon product of the same name or indeed
> "upstream", this is an external project where Plasma needs 1.0 which isn't
> released yet. Hopefully it'll be released in time for our final one in the
> mean time tell distros to use git
> https://www.freedesktop.org/wiki/Distributions/AppStream/
> 
> = kweathercore
> 0.7 released in sep 2022 should build against Qt 6, tell distros to update
> their packages
> 
> = libquotient
> https://github.com/quotient-im/libQuotient/tags
> Current release from september builds for both Qt 5 and 6, just remind
> distros to update packaging.
> 
> = kdsoap6
> External project, Latest release builds with Qt 5 and 6 tell distros to
> package it
> https://github.com/KDAB/KDSoap/releases
> kio-extras needs it so needs a Qt 5 build too for KF5 apps
> 
> = kdsoap-ws-discovery-client
> KDE project part of release service,
> https://invent.kde.org/libraries/kdsoap-ws-discovery-client
> New release will build with Qt 5 and 6
> kio-extras needs it so needs a Qt 5 build as well as Qt 6 for KF5 apps
> 
> = kio-extras
> part of kde gear
> KF5 apps need Qt 5 build as well as Qt 6 although there's lots of clashing
> files
> 
> = qcoro
> https://github.com/danvratil/qcoro
> Latest release can build for Qt 5 and 6, tell distros to package it for both
> 
> = futuresql
> KDE library https://invent.kde.org/libraries/futuresql
> Latest release from May builds both Qt 5 and 6, tell distros to do both
> https://download.kde.org/stable/futuresql/
> 
> = kquickimageeditor
> https://invent.kde.org/libraries/kquickimageeditor.git
> A qml module needed for koko, skanpage, and neochat
> Last release was in October 2021 by Carl
> Master supports Qt 6, new release needed
> 
> = qtkeychain
> External project used by tokodon, plasmatube, neochat, kmail, kasts and
> libquotient
> https://github.com/frankosterfeld/qtkeychain/releases
> Releases since May have Qt 6 support, tell distros to package for both Qt 5
> and 6 (or drop the Qt 5 depends)
> 
> = pulseaudio-qt
> https://invent.kde.org/libraries/pulseaudio-qt.git
> KDE library used by KDE connect
> Last release 2021 by Nicolas Fella
> master supports Qt 5 and 6 since last year
>

Re: print-manager and wacomtablet to Plasma

[Albert Astals Cid]

El dimarts, 31 d’octubre de 2023, a les 20:43:47 (CET), Jonathan Riddell va 
escriure:
> As discuccsed in Plasma meeting and just now with KDE gear release spods,
> Plasma would like to take over releases of print-manager and wacomtablet.
> This means renumbering the tars from e.g. 23.08 to 5.80.0.
> 
> Any issues?

What's the rationale for such move?

Cheers,
  Albert

> 
> Jonathan

Re: Release schedule proposal for the February MegaRelease

[Albert Astals Cid]

El dimarts, 26 de setembre de 2023, a les 0:28:15 (CEST), Albert Astals Cid va 
escriure:
> https://community.kde.org/Schedules/February_2024_MegaRelease
> 
> Beta 1 is during Qt World Summit that is not ideal but I guess doable?
> 
> I'll answer to this email with a few other emails things i thing we have to
> discuss to try to organize the discusion earlier.

No one has complained on the dates so let's make this official.

Cheers,
  Albert

> 
> Cheers,
>   Albert

Re: KDE Gear repositories switching to Qt6 - Re: Release schedule proposal for the February MegaRelease

[Albert Astals Cid]

El dijous, 28 de setembre de 2023, a les 20:33:30 (CEST), Heiko Becker va 
escriure:
> On Thursday, 28 September 2023 20:05:54 CEST, Volker Krause wrote:
> > On Dienstag, 26. September 2023 00:32:50 CEST Albert Astals Cid wrote:
> >> El dimarts, 26 de setembre de 2023, a les 0:28:15 (CEST),
> >> Albert Astals Cid
> >> va
> >> escriure: ...
> > 
> > My understanding would be that this is a dependency version change and
> > thus
> > this is already covered by the dependency freeze?
> 
> Usually the dependency freeze for Gear is even before the beta version, but
> usually we only have roughly one month between beta and release though.
> While this time it's three months.
> I admit it sounds a tad weird if a project switches Qts between beta and RC
> but given there's still plenty of time and that Christmas/New Year would be
> included, like Sune pointed out, I'd be in favour of rc1, too.

Ok, seems there's an agreement that "before RC1" is what we want, added it to 
the schedule page.

Cheers,
  Albert

> 
> Regards,
> Heiko

Re: MegaRelease Freezes - Re: Release schedule proposal for the February MegaRelease

[Albert Astals Cid]

El dimarts, 3 d’octubre de 2023, a les 7:13:52 (CEST), Justin Zobel va 
escriure:
> Plasma depends on kexiv in Gear so Gear would need to be before Plasma.

Why?

We just need that if someone changes API in kexiv they change the code in all 
places that use it.

Do you freeze parts of Plasma before other parts of Plasma just because they 
depend on each other? 

Probably not, then why do we need to do that procedure for kexiv?

Cheers,
  Albert

> 
> On 3/10/23 02:29, Aleix Pol wrote:
> > On Tue, Sep 26, 2023 at 12:29 AM Albert Astals Cid  wrote:
> >> El dimarts, 26 de setembre de 2023, a les 0:28:15 (CEST), Albert Astals
> >> Cid va>> 
> >> escriure:
> >>> https://community.kde.org/Schedules/February_2024_MegaRelease
> >>> 
> >>> Beta 1 is during Qt World Summit that is not ideal but I guess doable?
> >>> 
> >>> I'll answer to this email with a few other emails things i thing we have
> >>> to
> >>> discuss to try to organize the discusion earlier.
> >> 
> >> Do we want common times for dependency/feature/string freezes for all the
> >> 3
> >> products or different for each of them?
> >> 
> >> I have no particular opinion.
> > 
> > I'd say that by nature KF needs to freeze before Plasma & Apps.
> > 
> > I don't think there's any difference between apps and Plasma.
> > 
> > I'll include the Plasma and Frameworks lists JIC.
> > 
> > Aleix

Re: Release schedule proposal for the February MegaRelease

[Albert Astals Cid]

El dimarts, 3 d’octubre de 2023, a les 8:55:54 (CEST), Sune Vuorela va 
escriure:
> On 2023-09-25, Albert Astals Cid  wrote:
> > https://community.kde.org/Schedules/February_2024_MegaRelease
> > 
> > Beta 1 is during Qt World Summit that is not ideal but I guess doable?
> > 
> > I'll answer to this email with a few other emails things i thing we have
> > to
> > discuss to try to organize the discusion earlier.
> 
> Will all of these points come with tarballs, or only from a certain
> point?

I was thinking tarballs for all points.

Cheers,
  Albert

> 
> /Sune

Re: KDE Gear repositories switching to Qt6 - Re: Release schedule proposal for the February MegaRelease

[Albert Astals Cid]

El dimarts, 26 de setembre de 2023, a les 10:51:54 (CEST), Ben Cooksley va 
escriure:
> On Tue, Sep 26, 2023 at 11:32 AM Albert Astals Cid  wrote:
> > El dimarts, 26 de setembre de 2023, a les 0:28:15 (CEST), Albert Astals
> > Cid va
> > 
> > escriure:
> > > https://community.kde.org/Schedules/February_2024_MegaRelease
> > > 
> > > Beta 1 is during Qt World Summit that is not ideal but I guess doable?
> > > 
> > > I'll answer to this email with a few other emails things i thing we have
> > 
> > to
> > 
> > > discuss to try to organize the discusion earlier.
> > 
> > Until how kate do we allow KDE Gear repositories to switch to Qt6?
> > 
> > I'd vote for "need to be ready for RC1".
> 
> Sorry not quite sure what the question is here?
> 
> If what you were meaning was "at what point do we consider a Qt 6 version
> suitable for release" - then it being of release candidate quality would be
> a good signpost / line in the sand I think.

Of course being of "good quality" is a given, but if Okular-Qt6 "becomes of 
good quality 3 days before the release" we're obviously not going to include 
it in this release.

That is what I am asking here, when is the latest possible date we will accept 
a repository switching from Qt5 to Qt6.

I'm proposing before RC1.

Cheers,
  Albert

> 
> > Opinions?
> > 
> > Cheers,
> > 
> >   Albert
> 
> Cheers,
> Ben
> 
> > > Cheers,
> > > 
> > >   Albert

KDE Gear repositories switching to Qt6 - Re: Release schedule proposal for the February MegaRelease

[Albert Astals Cid]

El dimarts, 26 de setembre de 2023, a les 0:28:15 (CEST), Albert Astals Cid va 
escriure:
> https://community.kde.org/Schedules/February_2024_MegaRelease
> 
> Beta 1 is during Qt World Summit that is not ideal but I guess doable?
> 
> I'll answer to this email with a few other emails things i thing we have to
> discuss to try to organize the discusion earlier.

Until how kate do we allow KDE Gear repositories to switch to Qt6?

I'd vote for "need to be ready for RC1".

Opinions?

Cheers,
  Albert

> 
> Cheers,
>   Albert

MegaRelease versions - Re: Release schedule proposal for the February MegaRelease

[Albert Astals Cid]

El dimarts, 26 de setembre de 2023, a les 0:28:15 (CEST), Albert Astals Cid va 
escriure:
> https://community.kde.org/Schedules/February_2024_MegaRelease
> 
> Beta 1 is during Qt World Summit that is not ideal but I guess doable?
> 
> I'll answer to this email with a few other emails things i thing we have to
> discuss to try to organize the discusion earlier.

Please someone fill the version numbers for the KDE Plasma and KDE Frameworks 
pre-6.0 releases in the wiki above (and if someone disagrees with the numbers 
i chose for KDE Gear please shout).

Cheers,
  Albert

> 
> Cheers,
>   Albert

MegaRelease Freezes - Re: Release schedule proposal for the February MegaRelease

[Albert Astals Cid]

El dimarts, 26 de setembre de 2023, a les 0:28:15 (CEST), Albert Astals Cid va 
escriure:
> https://community.kde.org/Schedules/February_2024_MegaRelease
> 
> Beta 1 is during Qt World Summit that is not ideal but I guess doable?
> 
> I'll answer to this email with a few other emails things i thing we have to
> discuss to try to organize the discusion earlier.

Do we want common times for dependency/feature/string freezes for all the 3 
products or different for each of them?

I have no particular opinion.

Cheers,
  Albert

> 
> Cheers,
>   Albert

Release schedule proposal for the February MegaRelease

[Albert Astals Cid]

https://community.kde.org/Schedules/February_2024_MegaRelease

Beta 1 is during Qt World Summit that is not ideal but I guess doable?

I'll answer to this email with a few other emails things i thing we have to 
discuss to try to organize the discusion earlier.

Cheers,
  Albert

Re: Frameworks / Plasma/ Gear Release Schedule Plan

[Albert Astals Cid]

El diumenge, 10 de setembre de 2023, a les 19:50:48 (CEST), 
christ...@cullmann.io va escriure:
> On 2023-09-09 13:57, Luigi Toscano wrote:
>  Hi,
>  
>  yes, good point.
>  
>  Just a technical question: if we do this after that period, what is
>  the process to do it for an application belonging to Gear?
>  
>  Will it just be sufficient e.g. for Kate to drop the Qt 5 variants
>  in
>  
>  https://invent.kde.org/utilities/kate/-/blob/master/.kde-ci.yml?ref_typ
>  e=hea ds
>  
>  and
>  
>  https://invent.kde.org/utilities/kate/-/blob/master/.gitlab-ci.yml?ref_
>  type= heads
>  
>  and require KF 6 + Qt 6 in the CMake files or is there additional
>  stuff
>  that
>  needs updates to avoids one breaks stuff?
> >>> 
> >>> My guess is what you are describing plus updating things in
> >>> repo-metadata, i
> >>> can think of
> >>> 
> >>> dependencies/logical-module-structure
> >>>   to update the branch info (i.e. kf5-qt5 won't be master anymore, i
> >>> guess
> >>> point it to the latest stable branch)
> >>> 
> >>> dependencies/dependency-data-kf6-qt6
> >>>   to update the dependency info
> >>>   But this is autogenerated by Nico scripts nowadays so... maybe not?
> >>> or prod
> >>> him to run the script?
> >>> 
> >>> projects/*/*/i18n.json
> >>>   to update the i18n branch information
> >>> 
> >>> Anything else I am missing?
> >> 
> >> Hi,
> >> 
> >> Thanks for the additional pointers.
> >> 
> >> Given no one did seem to oppose so far, I would consider to switch
> >> Kate to Qt
> >> 6 in master next Wednesday and start the bit Qt 6 run :)
> > 
> > When you switch a branch to qt6, please remember to ping the
> > translation team
> > because we need to move the translations. Probably the best way is to
> > mention
> > the translation team in the merge request to sysadmin/repo-metadata.git
> > which
> > updates the content of the i18n.json file.
> 
> Thanks for the hint.
> 
> Just to be sure, perhaps I missed the docs, what would be needed in
> 
> https://invent.kde.org/sysadmin/repo-metadata/-/blob/master/projects-invent/
> utilities/kate/i18n.json?ref_type=heads
> 
> Now we have:
> 
> {"trunk": "none", "stable": "none", "stable_kf5": "release/23.08",
> "trunk_kf5": "master"}
> 
> Would it be something like:
> 
> {"trunk": "master", "stable": "none", "stable_kf5": "release/23.08",
> "trunk_kf5": "none"}

No.

trunk and master are kde4. 

You want trunk_kf6

Cheers,
  Albert

> 
> Greetings
> Christoph

Re: Frameworks / Plasma/ Gear Release Schedule Plan

[Albert Astals Cid]

El dimarts, 5 de setembre de 2023, a les 22:42:13 (CEST), 
christ...@cullmann.io va escriure:
> On 2023-09-04 22:59, Albert Astals Cid wrote:
> > El dilluns, 4 de setembre de 2023, a les 18:50:45 (CEST), David
> > Edmundson va
> > 
> > escriure:
> >> Following on from the last Akademy we checked where we were with our
> >> development progress in a meeting and settled on the following plan
> >> 
> >> for all 3 major parts:
> >>  - In KDE Gear master will be open for Qt6 code to land for those
> >> 
> >> ready to move. Not all apps need to port.
> > 
> > For the trigger happy among us...
> > 
> > This is a plan/proposal, let's give people at least one week to
> > comment/
> > disagree on it before making master Qt6-only for Gear apps.
> 
> Hi,
> 
> yes, good point.
> 
> Just a technical question: if we do this after that period, what is
> the process to do it for an application belonging to Gear?
> 
> Will it just be sufficient e.g. for Kate to drop the Qt 5 variants in
> 
> https://invent.kde.org/utilities/kate/-/blob/master/.kde-ci.yml?ref_type=hea
> ds
> 
> and
> 
> https://invent.kde.org/utilities/kate/-/blob/master/.gitlab-ci.yml?ref_type=
> heads
> 
> and require KF 6 + Qt 6 in the CMake files or is there additional stuff
> that
> needs updates to avoids one breaks stuff?

My guess is what you are describing plus updating things in repo-metadata, i 
can think of

dependencies/logical-module-structure
  to update the branch info (i.e. kf5-qt5 won't be master anymore, i guess 
point it to the latest stable branch)

dependencies/dependency-data-kf6-qt6
  to update the dependency info 
  But this is autogenerated by Nico scripts nowadays so... maybe not? or prod 
him to run the script?

projects/*/*/i18n.json
  to update the i18n branch information

Anything else I am missing?

Cheers,
  Albert

> 
> Greetings
> Christoph
> 
> >>  - The KDE Gear release will move by 2 months to allow for the extra
> >> 
> >> time needed for testing initial Qt6 changes
> >> 
> >>  - An Alpha will be made in November  (a soft freeze in Plasma terms)
> >>  
> >>  - Betas/RCs will be made throughout December and January (3 releases,
> >> 
> >> 3 weeks apart)
> >> 
> >>  - Final release of all 3 major parts in sync in February
> >> 
> >> Due to the delay of KDE Gear by an additional patch release of 23.08
> >> will be made.
> > 
> > Or maybe even two if there's bugfixes flowing.
> > 
> > Cheers,
> > 
> >   Albert
> >> 
> >> David Edmundson

Re: KHealthCertificate in Gear

[Albert Astals Cid]

El dilluns, 4 de setembre de 2023, a les 17:16:29 (CEST), Volker Krause va 
escriure:
> On Dienstag, 29. August 2023 00:07:34 CEST Albert Astals Cid wrote:
> > El divendres, 25 d’agost de 2023, a les 16:15:13 (CEST), Volker Krause va
> > 
> > escriure:
> > > Hi,
> > > 
> > > it looks like we missed KHealthCertificate (https://invent.kde.org/pim/
> > > khealthcertificate) when dissolving Mobile Gear, and it's currently not
> > > covered by automated releases. This went unnoticed as it hasn't gotten
> > > API
> > > changes recently, only a few data updates, but I'd like to fix this as
> > > we
> > > have things depending on it.
> > > 
> > > So I'd suggest we include it in 23.12, assuming we don't want to add
> > > things
> > > to the 23.08 series at this point.
> > 
> > Seems it was done on purpose?
> > 
> > https://invent.kde.org/teams/plasma-mobile/issues/-/issues/186
> > 
> > I don't particularly mind if it goes in KDE Gear but whoever wrote that
> > table seems that decided it's not what was wanted for KHealthCertificate?
> 
> oh, interesting... why/how was that decided? 

I've no idea :D

Devin Lin (cc-ed) wrote that issue, so maybe he knows?

Cheers,
  Albert

> I don't remember being involved
> in that, and I'm kinda the maintainer, and responsible for one of its main
> consumers...
> 
> It does seem to be based on the assumption of moving to KF instead of Gear
> though, which isn't really necessary nor intended here.
> 
> Regards,
> Volker

Re: Frameworks / Plasma/ Gear Release Schedule Plan

[Albert Astals Cid]

El dilluns, 4 de setembre de 2023, a les 18:50:45 (CEST), David Edmundson va 
escriure:
> Following on from the last Akademy we checked where we were with our
> development progress in a meeting and settled on the following plan
> for all 3 major parts:
> 
>  - In KDE Gear master will be open for Qt6 code to land for those
> ready to move. Not all apps need to port.

For the trigger happy among us...

This is a plan/proposal, let's give people at least one week to comment/
disagree on it before making master Qt6-only for Gear apps.

> 
>  - The KDE Gear release will move by 2 months to allow for the extra
> time needed for testing initial Qt6 changes
> 
>  - An Alpha will be made in November  (a soft freeze in Plasma terms)
> 
>  - Betas/RCs will be made throughout December and January (3 releases,
> 3 weeks apart)
> 
>  - Final release of all 3 major parts in sync in February
> 
> Due to the delay of KDE Gear by an additional patch release of 23.08
> will be made.

Or maybe even two if there's bugfixes flowing.

Cheers,
  Albert

> 
> David Edmundson

Re: KHealthCertificate in Gear

[Albert Astals Cid]

El divendres, 25 d’agost de 2023, a les 16:15:13 (CEST), Volker Krause va 
escriure:
> Hi,
> 
> it looks like we missed KHealthCertificate (https://invent.kde.org/pim/
> khealthcertificate) when dissolving Mobile Gear, and it's currently not
> covered by automated releases. This went unnoticed as it hasn't gotten API
> changes recently, only a few data updates, but I'd like to fix this as we
> have things depending on it.
> 
> So I'd suggest we include it in 23.12, assuming we don't want to add things
> to the 23.08 series at this point.

Seems it was done on purpose?

https://invent.kde.org/teams/plasma-mobile/issues/-/issues/186

I don't particularly mind if it goes in KDE Gear but whoever wrote that table 
seems that decided it's not what was wanted for KHealthCertificate?

Cheers,
  Albert

> 
> Thanks,
> Volker

Re: KDE Gear 23.08.0 packages available for packagers

[Albert Astals Cid]

El divendres, 18 d’agost de 2023, a les 11:04:58 (CEST), Heiko Becker va 
escriure:
> Hello packagers,
> 
> tarballs are available at the usual place under
> "stable/release-service/23.08.0".
> 
> Please report any issues, release is planned next Thursday.
> 
> Revisions and hashes can be found at https://invent.kde.org/-/snippets/2798
> and a preliminary changelog from 23.07.90 at
> https://invent.kde.org/-/snippets/2799
> 
> The tars are signed with my public key with the follow fingerprint
> D81C0CB38EB725EF6691C385BB463350D6EF31EF.

Would it make sense to re-spin kio-extras to include the last minute 
¿regression? fix of 

https://invent.kde.org/network/kio-extras/-/commit/30c4da4a91a25c3e44b7558d14e3728c2d9aa8cd

Cheers,
  Albert

> 
> Thanks for packaging,
> Heiko

KDE Gear 23.08 RC is released

[Albert Astals Cid]

https://kde.org/info/releases-23.07.90/

https://community.kde.org/KDE_Gear/23.08_Release_notes

Revisions and hashes at https://pastebin.com/raw/XJzJVcyp

Please test :)

Cheers,
  Albert

Re: Suggestion to drop kopete from KDE Gear

[Albert Astals Cid]

El dilluns, 31 de juliol de 2023, a les 10:48:50 (CEST), Jonathan Riddell va 
escriure:
> I'd agree on this having taken a quick look at it, I can't see a useful
> function for this app any more.

If we remove it, i would like to delay this to 23.12 given we're already in 
beta for 23.08.

Also gives people that may care about it to fix things if needed.

Cheers,
  Albert

> 
> Jonathan
> 
> On Fri, 28 Jul 2023 at 22:15, Heiko Becker  wrote:
> > Hello,
> > 
> > I wanted to keep kopete at least buildable against recent version of its
> > dependencies by removing some obsolete parts. But it occured to me that if
> > I were to continue with that, there wouldn't be much left. It suffers from
> > the same problems with dead or (at least dying) protocols I wrote down for
> > ktp [1], so I'll just add some relevant things affecting kopete:
> > 
> > - Contrary to ktp it doesn't use pidgin for ICQ/AIM, but a custom
> > implementation, the result is the same. AIM ceased to exist and ICQ
> > changed
> > its protocol (and thus kopete silently fails to with the latter).
> > - XMPP/Jabber allows to connect, but joining a room crashes kopete, which
> > matches a bug report from 2019 [2]
> > - winpopup was apparently discontinued after Windows XP
> > - qq: I'm hesistant to give them my phone number to manually register an
> > account (the link behind the register button times out). Pidgin removed
> > support for this in 2011, which is roughly the same time a non-porting
> > commit touched the code and there is a bug report that it indeed doesn't
> > work [3]
> > 
> > I didn't have/find an instance to test Bonjour and my distro doesn't
> > provide a package for libmeanwhile, so no testing of these.
> > 
> > In addition, it has a very long list of (partly very old) bugs [4] (no
> > idea
> > how many, bugzilla stops after 500), and my impression from testing a few
> > is that many of them are easily reproduceably today.
> > 
> > As much as I used kopete for chatting back in the day, I seriously think
> > it's broken enough to stop shipping it with Gear, if nobody surprisingly
> > steps up and does at least some basic maintenance.
> > 
> > If you know anybody who's still around and cares for kopete, please feel
> > free to bring this mail to their attention.
> > 
> > Regards,
> > Heiko
> > 
> > [1] https://mail.kde.org/pipermail/release-team/2023-June/013080.html
> > [2] https://bugs.kde.org/show_bug.cgi?id=412228
> > [3] https://bugs.kde.org/show_bug.cgi?id=460744
> > [4]
> > 
> > https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRM
> > ED&bug_status=ASSIGNED&bug_status=REOPENED&list_id=2429758&order=changedda
> > te%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=kopete&qu
> > ery_format=advanced

KDE Gear 23.08 Beta is released

[Albert Astals Cid]

https://kde.org/info/releases-23.07.80/

https://community.kde.org/KDE_Gear/23.08_Release_notes

Revisions and hashes at https://pastebin.com/raw/JXdrheHY

Please test :)

Known issues:
 * neochat does build if your libquotient doesn-t have E2EE, which you should 
totally have, but if for some reason you don-t and you can-t enable it, apply 
this https://invent.kde.org/network/neochat/-/merge_requests/1107 E2EE will 
become mandatory for neochat 23.12

Cheers,
  Albert

Re: Arianna in KDE Gear

[Albert Astals Cid]

El dimarts, 4 de juliol de 2023, a les 21:20:57 (CEST), Carl Schwan va escriure:
> Hello,
> 
> I would like to move Arianna to KDE Gear. Arianna is now mostly done and
> should not received a lot of feature update anymore.

No one has disagreed so it has now been added.

https://invent.kde.org/sysadmin/release-tools/-/commit/e02b1318772759013e6bbe19a3510ede8fe5d008

Please make sure it has an auto incrementing cmake version logic.

Cheers,
  Albert

> 
> Link to the repo: https://invent.kde.org/graphics/arianna
> 
> Cheers,
> Carl

Re: Suggestion to drop ktp from KDE Gear

[Albert Astals Cid]

El dilluns, 26 de juny de 2023, a les 22:55:44 (CEST), Albert Astals Cid va 
escriure:
> El divendres, 23 de juny de 2023, a les 0:52:46 (CEST), Heiko Becker va
> 
> escriure:
> > On Wednesday, 21 June 2023 21:48:16 CEST, Albert Astals Cid wrote:
> > > El dimecres, 21 de juny de 2023, a les 18:35:28 (CEST), Jonathan Riddell
> > > va
> > > 
> > > escriure:
> > >> I'd like to suggest dropping ktp packages from the next KDE Gear
> > >> release.
> > >> Telepathy upstream is unmaintained, KTP is unmaintained and discussions
> > >> with one of the original authors says it should be dropped.
> > >> 
> > >> Modules we release are:
> > >> ktp-accounts-kcm ...
> > > 
> > > Is it working? Unless it isn't i don't see why we need to drop it.
> > 
> > Not very pleasantly...
> > 
> > I tried:
> > 
> > - ICQ: doesn't work because pidgin remove support for it in 2021 because
> > the protocol changed in 2017
> > - AIM: I never had an account there, but the situation is exactly the same
> > as for ICQ
> > - Skype: Doesn't work, but probably due to me missing
> > https://github.com/EionRobb/skype4pidgin
> > - Telegram: Way too shady for me to give them my phone number and I'm
> > missing telepathy-morse anyway, so no idea if it works
> > - Office/Bonjour: These are a tad weird, they don't error out, but the UI
> > is so basic that I'm not sure how to do something with it
> > - Google Hangouts: Asks to sign in with google, but that errors out after
> > entering an email, maybe because it was shut down on November 1, 2022
> > - Yahoo: piding has removed it in 2016, because they totally changed the
> > protocol after August 5th, 2016
> > - XMPP seems to somewhat work and I could enter a chat room
> > - GG (former Gadu-Gadu): Can't register "The ability to create a new
> > account has been blocked."
> 
> Thanks for the detailed analysis.
> 
> It seems XMPP is the only thing that seems to work.
> 
> Given that kopete seems to also support XMPP I woud not be against removing
> ktp for 23.08 given the big support for removing it.
> 
> Hoping that existing users of KTP can keep it installed without their
> distributions forcing them to remove it.
> 
> If someone objects to the removal please make it clear before July 16th.

This has now been done.

https://invent.kde.org/sysadmin/release-tools/-/commit/9e8b75d787a33405a68379364d9637e7e7001328

Cheers,
  Albert

> 
> Cheers,
>   Albert
> 
> > So, at the very least we should remove some accounts, where the respective
> > service doesn't exist/work anymore and remove ktp-call-ui, which depends
> > on
> > qt-gstreamer which is realldy dead and archived upstream and a pain to
> > keep
> > building (no idea how to test it...).
> > 
> > But given the above, the fact that nobody seemed to care enough to notice
> > that, the mentioned maintenance state of the telepathy stack and the
> > apparently very low number of people willing to invest time on its
> > maitenance on our side, I'm in favour of just dropping it.
> > 
> > Regards,
> > Heiko

Re: Suggestion to drop ktp from KDE Gear

[Albert Astals Cid]

El divendres, 23 de juny de 2023, a les 0:52:46 (CEST), Heiko Becker va 
escriure:
> On Wednesday, 21 June 2023 21:48:16 CEST, Albert Astals Cid wrote:
> > El dimecres, 21 de juny de 2023, a les 18:35:28 (CEST), Jonathan Riddell
> > va
> > 
> > escriure:
> >> I'd like to suggest dropping ktp packages from the next KDE Gear release.
> >> Telepathy upstream is unmaintained, KTP is unmaintained and discussions
> >> with one of the original authors says it should be dropped.
> >> 
> >> Modules we release are:
> >> ktp-accounts-kcm ...
> > 
> > Is it working? Unless it isn't i don't see why we need to drop it.
> 
> Not very pleasantly...
> 
> I tried:
> 
> - ICQ: doesn't work because pidgin remove support for it in 2021 because
> the protocol changed in 2017
> - AIM: I never had an account there, but the situation is exactly the same
> as for ICQ
> - Skype: Doesn't work, but probably due to me missing
> https://github.com/EionRobb/skype4pidgin
> - Telegram: Way too shady for me to give them my phone number and I'm
> missing telepathy-morse anyway, so no idea if it works
> - Office/Bonjour: These are a tad weird, they don't error out, but the UI
> is so basic that I'm not sure how to do something with it
> - Google Hangouts: Asks to sign in with google, but that errors out after
> entering an email, maybe because it was shut down on November 1, 2022
> - Yahoo: piding has removed it in 2016, because they totally changed the
> protocol after August 5th, 2016
> - XMPP seems to somewhat work and I could enter a chat room
> - GG (former Gadu-Gadu): Can't register "The ability to create a new
> account has been blocked."

Thanks for the detailed analysis.

It seems XMPP is the only thing that seems to work.

Given that kopete seems to also support XMPP I woud not be against removing 
ktp for 23.08 given the big support for removing it.

Hoping that existing users of KTP can keep it installed without their 
distributions forcing them to remove it.

If someone objects to the removal please make it clear before July 16th.

Cheers,
  Albert


> 
> So, at the very least we should remove some accounts, where the respective
> service doesn't exist/work anymore and remove ktp-call-ui, which depends on
> qt-gstreamer which is realldy dead and archived upstream and a pain to keep
> building (no idea how to test it...).
> 
> But given the above, the fact that nobody seemed to care enough to notice
> that, the mentioned maintenance state of the telepathy stack and the
> apparently very low number of people willing to invest time on its
> maitenance on our side, I'm in favour of just dropping it.
> 
> Regards,
> Heiko

Re: KDE Gear 23.08 proposed schedule

[Albert Astals Cid]

El dissabte, 17 de juny de 2023, a les 13:12:11 (CEST), Heiko Becker va 
escriure:
> On Saturday, 17 June 2023 12:47:05 CEST, Albert Astals Cid wrote:
> >> On Friday, 16 June 2023 22:56:39 CEST, Albert Astals Cid wrote: ...
> > 
> > ok, another proposal, pushing things forward enough that i'll
> > be back home (on
> > July 25) to handle Beta and RC.
> > 
> > What do you think?
> > 
> > July 20: Dependency Freeze
> > 
> > July 27: Beta
> > 
> > August 10: RC
> > 
> > August 17: .0 Tagging
> > August 24: .0 Release
> > 
> > 
> > Sept 11: .1 tag
> > Sept 14: .1 release
> > 
> > .2 and .3 tags keep the same date
> 
> That would work for me.

Ok, it's official then. I'll email and blog about it.

Cheers,
  Albert

Re: Suggestion to drop ktp from KDE Gear

[Albert Astals Cid]

El dijous, 22 de juny de 2023, a les 11:18:08 (CEST), Jonathan Riddell va 
escriure:
> The distros don't want it

Nobody forces them to carry it, but FWIW 8% of all Arch users[*] have it 
installed, compared to 36% having dolphin installed. Seems a non negligible 
amount to me

> the authors don't want it

Authors stopped being authors long time ago so their opinion is not really 
worth a lot more than yours or mine.

> the Telepathy project
> is bitrotting and has had no part of it released in over 2 years.

You still haven't answered my question, does it not work? 
Does it have any particular security bug that will cause harm to the users? 
Because I don't understand why we should stop shipping things that users use.

And yes, i know that the fact that we stop shipping doesn't 100% mean that 
distros will stop shipping it, but we know it means it most probably will 
happen.

Cheers,
  Albert

> Sometimes you just need to be like Elsa and say Let it Go
> https://www.youtube.com/watch?v=L0MK7qz13bU
> 
> Jonathan

* That have enabled package stats

Re: Suggestion to drop ktp from KDE Gear

[Albert Astals Cid]

El dimecres, 21 de juny de 2023, a les 18:35:28 (CEST), Jonathan Riddell va 
escriure:
> I'd like to suggest dropping ktp packages from the next KDE Gear release.
> Telepathy upstream is unmaintained, KTP is unmaintained 

Please read 

https://tsdgeos.blogspot.com/2021/06/everything-we-release-in-kde-gear-is.html

Best Regards,
  Albert

> and discussions
> with one of the original authors says it should be dropped.
> 
> Modules we release are:
> ktp-accounts-kcm
> ktp-approver
> ktp-auth-handler
> ktp-call-ui
> ktp-common-internals
> ktp-contact-list
> ktp-contact-runner
> ktp-desktop-applets
> ktp-filetransfer-handler
> ktp-kded-module
> ktp-send-file
> ktp-text-ui
> 
> Previously discussed in 2017
> https://mail.kde.org/pipermail/release-team/2017-August/010494.html
> 
> https://www.mail-archive.com/release-team@kde.org/msg10454.html
> 
> Jonathan

Re: Suggestion to drop ktp from KDE Gear

[Albert Astals Cid]

El dimecres, 21 de juny de 2023, a les 18:35:28 (CEST), Jonathan Riddell va 
escriure:
> I'd like to suggest dropping ktp packages from the next KDE Gear release.
> Telepathy upstream is unmaintained, KTP is unmaintained and discussions
> with one of the original authors says it should be dropped.
> 
> Modules we release are:
> ktp-accounts-kcm
> ktp-approver
> ktp-auth-handler
> ktp-call-ui
> ktp-common-internals
> ktp-contact-list
> ktp-contact-runner
> ktp-desktop-applets
> ktp-filetransfer-handler
> ktp-kded-module
> ktp-send-file
> ktp-text-ui

Is it working? Unless it isn't i don't see why we need to drop it.

Cheers,
  Albert

> 
> Previously discussed in 2017
> https://mail.kde.org/pipermail/release-team/2017-August/010494.html
> 
> https://www.mail-archive.com/release-team@kde.org/msg10454.html
> 
> Jonathan

Re: KDE Gear 23.08 proposed schedule

[Albert Astals Cid]

El dissabte, 17 de juny de 2023, a les 10:44:27 (CEST), Heiko Becker va 
escriure:
> On Friday, 16 June 2023 22:56:39 CEST, Albert Astals Cid wrote:
> > This time we are MEGA late.
> > 
> > The proposed dependency freeze would be in a little less than 2 weeks.
> > 
> > But if we move it forward we have Akademy in the middle and
> > that makes things
> > harder to plan
> > 
> > https://community.kde.org/Schedules/KDE_Gear_23.08_Schedule
> 
> Despite that, 4 weeks between Beta and RC do seem a bit long though?
> 
> Other than that, I'll be away and mostly without Internet from 9th - 14th
> of August, so I couldn't take care of 23.08.0.

ok, another proposal, pushing things forward enough that i'll be back home (on 
July 25) to handle Beta and RC.

What do you think?

July 20: Dependency Freeze

July 27: Beta

August 10: RC 

August 17: .0 Tagging 
August 24: .0 Release


Sept 11: .1 tag
Sept 14: .1 release

.2 and .3 tags keep the same date

> 
> > We need to agree on this in less than a week.
> 
> Regards,
> Heiko

KDE Gear 23.08 proposed schedule

[Albert Astals Cid]

This time we are MEGA late.

The proposed dependency freeze would be in a little less than 2 weeks.

But if we move it forward we have Akademy in the middle and that makes things 
harder to plan

https://community.kde.org/Schedules/KDE_Gear_23.08_Schedule

We need to agree on this in less than a week.

Cheers,
  Albert

Re: kio-extras and the KF5/KF6 period

[Albert Astals Cid]

El dijous, 25 de maig de 2023, a les 12:51:32 (CEST), Nicolas Fella va 
escriure:
> Hi,
> 
> Am 17.05.23 um 00:02 schrieb Albert Astals Cid:
> > kio-extras provides plugins for kio.
> > 
> > So KF5 applications want a KF5 kio-extras and KF6 applications want a KF6
> > kio- extras.
> 
> This is also the case in more places, e.g. Breeze/Oxygen and
> plasma-integration, so having a unified approach would make sense.
> 
> > If we're going to support a period on which we ship both Kf5 and KF6 based
> > applications we need to:
> > 
> > Make sure kf5 and kf6 are coinstallable.
> > 
> > a) release two tarballs, one for each KF
> 
> In some cases, where there is a large enough divergence between the 5
> and 6 code we might want to have separate branches to maintain those
> (e.g. master is Qt6 and we have a qt5-compat branch).
> 
> Having separate branches would imply separate tarballs.
> 
> How would this work with version numbers and tags? We'd have something
> like v23.08.0-qt5 and v23.08.0-qt6?

probably the branch name in front? I have the feeling it'd confuse the 
"version number extractors" a bit less.

So basically kio-extras-qt5-xxx and kio-extras-qt6-xxx (or without the qt) (or 
with kf instead of qt).

> 
> > b) release one tarball that compiles both for kf5 and kf6
> 
> This would be my preferred approach for things with little divergence
> between 5 and 6, i.e. not enough divergence to justify a separate branch.
> 
> > c) just release the kf6 tarball, stop releasing the kf5 tarball but ask
> > distributions to still install it
> 
> You mean installing the last KF5-based release? How well this works
> would depend on the amount of non-bugfix work we want to put into the
> Qt5 variant.

This is basically a variant of a) in which no longer release a KF5-based-
tarball but the distributions do some kind of renaming to make sure both the 
"old" KF5-based package and the "new" KF6-based package can both be installed 
at the same time.

Cheers,
  Albert

> 
> For Breeze in particular this could mean that the appearance of Qt5 and
> Qt6 apps could get out of sync.
> 
> > What's everyone's preference?
> > 
> > Cheers,
> > 
> >Albert
> 
> Cheers
> 
> Nico

[sysadmin/release-tools] /: Remove kfloppy from KDE Gear

[Albert Astals Cid]

Git commit 7f90de6cdb8eecb423657c88cfb3b37797c6fab3 by Albert Astals Cid.
Committed on 20/05/2023 at 09:40.
Pushed by aacid into branch 'master'.

Remove kfloppy from KDE Gear

https://mail.kde.org/pipermail/kde-devel/2023-April/001786.html

CCMAIL: release-team@kde.org

M  +0-1modules.git

https://invent.kde.org/sysadmin/release-tools/commit/7f90de6cdb8eecb423657c88cfb3b37797c6fab3

diff --git a/modules.git b/modules.git
index 14e0c7d..a66df1f 100644
--- a/modules.git
+++ b/modules.git
@@ -52,7 +52,6 @@ kcalc   master
 kcharselect master
 kdebugsettings  master
 kdf master
-kfloppy master
 kgpgmaster
 ktimer  master
 kwalletmanager  master

kio-extras and the KF5/KF6 period

[Albert Astals Cid]

kio-extras provides plugins for kio.

So KF5 applications want a KF5 kio-extras and KF6 applications want a KF6 kio-
extras.

If we're going to support a period on which we ship both Kf5 and KF6 based 
applications we need to:

Make sure kf5 and kf6 are coinstallable.

a) release two tarballs, one for each KF
b) release one tarball that compiles both for kf5 and kf6 
c) just release the kf6 tarball, stop releasing the kf5 tarball but ask 
distributions to still install it


What's everyone's preference?

Cheers,
  Albert