Moving KDevelop to Release service coverage?

[Aleix Pol]

+1

On Wed, Oct 20, 2021 at 8:23 PM Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
>
> 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
>
>