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