Moving KDevelop to Release service coverage?
"Friedrich W. H. Kossebau" <[email protected]> Wed, 20 Oct 2021 20:22:55 +0200
| Newsgroups | gmane.comp.kde.devel.kdevelop |
|---|---|
| Organization | KDE |
| Message-ID | <2128689.trFEzC8vaQ@klux> |
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