Re: VDG application design sprint?
What else is missing to put together this sprint? I can facilitate. On April 17, 2024 at 1:40:09 PM, Noah Davis (noaha...@gmail.com) wrote: Any month except for April (too soon) and September (Akademy 2024), up to 1 week in duration On Thu, Apr 11, 2024 at 10:26 AM Nicolas Fella wrote: > > On 1/24/23 00:43, Nicolas Fella wrote: > > Hi, > > > > I think it would make sense for us to have a VDG sprint of sorts in the > > near-ish future. This would allow to discuss some larger design topics > > and set a vision for the longer-term future. I believe this is important > > for us to be able to work together effectively. > > > > I'd suggest to focus on application design topics, like layout, > > structure, and arrangement of apps, and less on things like Plasma and > > styles/themes. I'd also suggest to approach this more from a design/UX > > PoV and don't let us be driven by implementation details. But these are > > just my suggestions that are subject to debate. > > > > Time/place/modality is all to be discussed, I'm mainly writing this to > > gauge interest, so if you are interested let me know. > > Hi, > > I'd like to pick up this topic again since it's as relevant as ever. > > I have a possible venue in central Germany where I live (in an old > castle, so in good KDE tradition). We could accomodate up to 10 people > there, and more people nearby if needed. > > For those interested, what would be a good timeframe in terms of dates > and duration? > > Cheers > > Nico >
Re: CI moved to Qt 6.7 for Linux builds
kdiff3 will make one or two releases but needs only frameworks. This support will end in three months. master is qt6 only now. Apr 20, 2024 8:35:40 PM Ben Cooksley : > Hi all, > > I have just flipped the switch that has moved the CI system over to using Qt > 6.7 for Linux builds on our SUSE images. > > Should you see any issues with builds failing as a result of packages being > missing in the registry then please submit a merge request to > sysadmin/ci-management to ensure that build dependency is added to our seed > jobs. > > I'll leave the Qt 6.6 package registry and container images in place for > another week or so then will schedule them for removal. > > As part of this I have also updated the list of projects with Qt 6 only > master branches. Any residual Qt 5 build artifacts the CI system was holding > for those projects have now been purged, which may impact downstream projects > that depend on those projects that are still on Qt 5. > > On an adjacent note, i'd also like to schedule removing CI support for > release/23.08 and Plasma/5.27 builds (by purging all their binaries we > currently hold) for the Qt 5.15 series. > > While checking however I note that several projects still have activity on > those branches. Can we please confirm whether any further releases are > expected, as i'd prefer to remove anything that isn't being properly > maintained anymore. > > Thanks, > Ben signature.asc Description: PGP signature
Re: CI moved to Qt 6.7 for Linux builds
kdiff3 will make one or two releases but needs only frameworks. This support will end in three months. master is qt6 only now. Apr 20, 2024 8:35:40 PM Ben Cooksley : > Hi all, > > I have just flipped the switch that has moved the CI system over to using Qt > 6.7 for Linux builds on our SUSE images. > > Should you see any issues with builds failing as a result of packages being > missing in the registry then please submit a merge request to > sysadmin/ci-management to ensure that build dependency is added to our seed > jobs. > > I'll leave the Qt 6.6 package registry and container images in place for > another week or so then will schedule them for removal. > > As part of this I have also updated the list of projects with Qt 6 only > master branches. Any residual Qt 5 build artifacts the CI system was holding > for those projects have now been purged, which may impact downstream projects > that depend on those projects that are still on Qt 5. > > On an adjacent note, i'd also like to schedule removing CI support for > release/23.08 and Plasma/5.27 builds (by purging all their binaries we > currently hold) for the Qt 5.15 series. > > While checking however I note that several projects still have activity on > those branches. Can we please confirm whether any further releases are > expected, as i'd prefer to remove anything that isn't being properly > maintained anymore. > > Thanks, > Ben signature.asc Description: PGP signature
Re: CI moved to Qt 6.7 for Linux builds
kdiff3 will make one or two releases but needs only frameworks. This support will end in three months. master is qt6 only now. Apr 20, 2024 8:35:40 PM Ben Cooksley : > Hi all, > > I have just flipped the switch that has moved the CI system over to using Qt > 6.7 for Linux builds on our SUSE images. > > Should you see any issues with builds failing as a result of packages being > missing in the registry then please submit a merge request to > sysadmin/ci-management to ensure that build dependency is added to our seed > jobs. > > I'll leave the Qt 6.6 package registry and container images in place for > another week or so then will schedule them for removal. > > As part of this I have also updated the list of projects with Qt 6 only > master branches. Any residual Qt 5 build artifacts the CI system was holding > for those projects have now been purged, which may impact downstream projects > that depend on those projects that are still on Qt 5. > > On an adjacent note, i'd also like to schedule removing CI support for > release/23.08 and Plasma/5.27 builds (by purging all their binaries we > currently hold) for the Qt 5.15 series. > > While checking however I note that several projects still have activity on > those branches. Can we please confirm whether any further releases are > expected, as i'd prefer to remove anything that isn't being properly > maintained anymore. > > Thanks, > Ben signature.asc Description: PGP signature
Re: AppStream Metadata with our releases
On 3/25/24 23:27, Albert Astals Cid wrote: El dilluns, 25 de març de 2024, a les 19:37:07 (CET), Volker Krause va escriure: As Itinerary was mentioned, the process there currently is to run David's KF changelog script over all repositories in Itinerary's dependency chain and take the top 5 or so most visible/important changes (which here are actually often from other repositories). The commit adding the release to appstream is my reminder for that currently, but there's other ways to do that, so for Itinerary the proposed change wouldn't make much of a difference either way. This brings an interesting point, it would seem that the right time to add the release description is at the end of the release cycle when you know all the changes, not when a particular commit is made. I like what Itinerary does. Idea: we run this script nightly in repos with AppStream metadata so that it appends changes newly committed changes to the notes quickly after they've made, not just all in one big blog towards the end of the release. Then a few more changes could make it acceptable to roll it out universally: - When run for this purpose, modify the script to ignore anything that doesn't fix a bug report, so the changelog doesn't end up too long and spammy. - Allow repos to opt out if they prefer to manually write/curate their release notes. Nate
KDE Gear 24.05 branches created
Make sure you commit anything you want to end up in the KDE Gear 24.05 releases to them Next Dates April 25 2024: 24.05 Freeze and Beta (24.04.80) tag & release May 9, 2024: 24.05 RC (24.04.90) Tagging and Release May 16, 2024: 24.05 Tagging May 23, 2024: 24.05 Release https://community.kde.org/Schedules/KDE_Gear_24.05_Schedule Cheers, Albert
Re: AppStream Metadata with our releases
El divendres, 22 de març del 2024, a les 0:37:00 (CEST), Julius Künzel va escriure: > Hi! > > (This mail goes to multiple lists, please reply to kde-devel) > > With Flathub beeing more strict on its AppStream metadata guidlines [1] > there is yet another spotlight on AppStream metadata. > > AppStream metadata are consumed by app stores like Flathub, Snapcraft, > Discover, our scripts to submit apps to the Microsoft Store and last but > not least by apps.kde.org [2]. > > For release info in particular the quality guidelines say: "Make sure all > your releases have release notes, even minor ones." [3] As I think this > makes perfectly sense, I like to propose two things that seem straight > forward to me: > > - We should not remove older releases from the AppStream data as already > suggested by Carl in a merge request [4]. I'd go for https://invent.kde.org/sysadmin/release-tools/-/merge_requests/48/diffs instead. Cheers, Albert > > - Also it would be convenient to add noteworthy changes to the metadata > together with the related code change. However at the moment for KDE Gear > the release is usually only added to the metadata a few days before > tagging. Would it be possible to add the next minor release to the release > branch right after the current one has been released and the next major > release to master ones the upcoming version has been branched? > > I belive this makes it easier for developers to contribute to the release > meta info and I hope it hence raises motivation to do so. > > I am happy to hear your opionions, thoughts and concerns! > > Cheers, > Julius > > [1] https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines > [2] https://apps.kde.org/ > [3] > https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/quality-g > uidelines/#release-notes [4] > https://invent.kde.org/sysadmin/appstream-metainfo-release-update/-/merge_r > equests/6 > > Julius Künzel > Volunteer KDE Developer, mainly hacking Kdenlive > KDE GitLab: www.invent.kde.org/jlskuz https://invent.kde.org/jlskuz > Matrix: @jlskuz:kde.org https://go.kde.org/matrix/#/@jlskuz:kde.org
KDE Frameworks with failing CI (kf5) (21 April 2024)
Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. Good news: All repos CI is passing Cheers, Albert
KDE Frameworks with failing CI (master) (21 April 2024)
Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. Good news: All repos CI is passing Cheers, Albert
