Moving KDevelop to Release service coverage?

Friedrich W. H. Kossebau kossebau at kde.org
Wed Oct 20 19:22:55 BST 2021


Hi,

my request for a new release of KDevelop showed there is no active release 
coordinator at the moment, only (which still is good, so thanks for all those 
who offered themselves) people ready to help or do things on a ping
But with no-one in the driving seat, the release train is idling at the 
station, having the cargo of bug fixes or improvements rotting due to broken 
feedback cycle. Not good for a vivid future and sad for any work done.
And I have seen also with myself motivation is lower to fix or add something 
if there is no release planned. And after all the mantra release-often-and-
early is not without a reason.

So unless someone takes over here the responsibility of an coordinator and is 
actively pushing things with lots of energy, I would like to propose to have 
KDevelop be covered by the Release service for now, to get the tasks covered 
of someone deciding on a schedule as well as doing the release work like 
version bumping, tagging, source tarball creation and upload.

Advantage:
The problem of a quick turn-around of fixes and improvements is solved at 
least for classic Linux/*BSD distributions picking up source tarballs.

Disadvantage:
The awkward release-service-oriented branch names and version numbers. I would 
propose to use the 5.6.xyz (with xzy generated from the release service data) 
approach here, so the major and minor number is still under KDevelop control 
and to match whatever semantics it has, while the patch level is based on the 
Release service number.

Some tasks would remain unsolved by that change though:

App bundles:
Doing bundled apps like AppImage, Windows installer, etc. still needs to be 
done by KDevelop volunteers as before, though perhaps someone might be able to 
get things more integrated with KDE's binary factory and one day the 
generation and upload can be completely automated as well.
So the webpage kdevelop.org/download would as before only be filled & updated 
manually, once someone has done new packages/bundles.

KDevelop news:
Someone needs to write announcements on schedule for the KDevelop website. 
Unless someone volunteers to care for that on the monthly basis as needed 
then, perhaps there could be simply a new entry "Switched to release service", 
so anyone looking things up on the news page gets to know that things are 
alife and where to look instead for news (the KDE Gear announcements).

Switching back from Release service might be doable once there is again 
someone around with enough resources to fill the driver seat and press the Go 
paddle in KDevelop :) So this move is no lock-in for eternity.

While I currently have little time left for KDevelop, I would be available to 
do the needed adjustments on the build system in case it is decided to switch 
the Release service and also other coordination with the release service team. 
I already moved Konversation over to Release service in the last years, so 
there is some experience :) I would target KDE Gear 21.12 for this then.

Thursday, November 4, is the Dependency Freeze for KDE Gear 21.12 (see 
https://community.kde.org/Schedules/KDE_Gear_21.12_Schedule) so I would like 
to have a decision in time for that, i.e. setting a deadline here of WE 30/31 
October. Already going in parallel to ask Release service workers about the 
potential move, so things are prepared in case.

So, who would be in favour, who would not be in favour?

Cheers
Friedrich




More information about the KDevelop-devel mailing list