Re: Moving KDevelop to Release service coverage?

Milian Wolff <[email protected]> Thu, 21 Oct 2021 09:37:51 +0200
Newsgroups	gmane.comp.kde.devel.kdevelop
Message-ID	<6515094.vRmUtxFnbF@milian-workstation>
On Mittwoch, 20. Oktober 2021 20:22:55 CEST Friedrich W. H. Kossebau 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.

I'm all in favor, assuming the kind people doing the releases are up for the 
additional work.

> 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.

We could also bump the version numbers to be in line with the other KDE gear 
applciations, if that's needed. But I have to admit that I don't really know 
what exactly you are talking about here - can you give a more concrete 
example? We already use 5.6.xyz after all the way I see it?

> 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.

I have worked on the binary factory appimage generation for quite some time 
earlier this year, but it's extremely time consuming. Locally, I already 
succeeded in using docker with a centos setup to create the AppImages, see 
[1]. The remaining problems are keeping it up2date (usually not too hard) and 
more problematic actually integrating it properly with the KDE CI setup. Now 
that the CI has changed to gitlab, I'm totally out of the loop again.

[1]: https://invent.kde.org/mwolff/kf5-appimage-centos7

> 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).

Personally, writing news and so far is way more of a hindrance for me to 
creating new releases than running a few scripts and uploading the tarballs.

> 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.

I don't see a need for that, frankly. KDevelop is not dead, but it's stagnant. 
Personally, I think this is good, as it's pretty solid for what I'm using it 
for all the time :)

> 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.

Thanks for the offer.

> 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?

Let's go for it, I say!

-- 
Milian Wolff
[email protected]
http://milianw.de
signature.asc (application/pgp-signature, 833 B)