CI moved to Qt 6.7 for Linux builds
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
CI moved to Qt 6.7 for Linux builds
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
CI moved to Qt 6.7 for Linux builds
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
Please cleanup old forks
Hi all, As part of routine maintenance on Invent (Gitlab) i've been reviewing the total amount of space currently being consumed by repositories. At this time, the top 100 largest repositories on Invent (we have 14,000 or so for context) are consuming around 21% of the total space. It would therefore be good if we could please clean this up. To add a bit of context, we currently have around 140GB of repositories, and a further 30GB of pooled repository data (shared among the canonical repository and it's forks). Those top 100 repositories currently use 30GB of space - so as much as all of the pools. Forks of KDevelop and docs-krita-org feature heavily on the list of large repositories. Of particular interest are old forks (created more than 2-3 years ago) as these are often not participating in Gitlab's mechanism to reduce the disk space taken by forks (known as pool repositories). As an additional note: please do not fork a fork, as these forks-of-forks cannot participate in a pool and must carry a full copy of the upstream repository data. If you have a situation where a network of forks of forks has developed please consider options to resolve this. I know Krita at least has this situation presently with their fork of various parts of Qt that is being maintained in people's personal namespaces. Thanks, Ben
Please cleanup old forks
Hi all, As part of routine maintenance on Invent (Gitlab) i've been reviewing the total amount of space currently being consumed by repositories. At this time, the top 100 largest repositories on Invent (we have 14,000 or so for context) are consuming around 21% of the total space. It would therefore be good if we could please clean this up. To add a bit of context, we currently have around 140GB of repositories, and a further 30GB of pooled repository data (shared among the canonical repository and it's forks). Those top 100 repositories currently use 30GB of space - so as much as all of the pools. Forks of KDevelop and docs-krita-org feature heavily on the list of large repositories. Of particular interest are old forks (created more than 2-3 years ago) as these are often not participating in Gitlab's mechanism to reduce the disk space taken by forks (known as pool repositories). As an additional note: please do not fork a fork, as these forks-of-forks cannot participate in a pool and must carry a full copy of the upstream repository data. If you have a situation where a network of forks of forks has developed please consider options to resolve this. I know Krita at least has this situation presently with their fork of various parts of Qt that is being maintained in people's personal namespaces. Thanks, Ben
Re: Proposal unify back our release schedules
On Fri, Apr 19, 2024 at 9:39 AM Kevin Ottens wrote: > Hello, > > ::most history snipped:: > > And then have a single big marketing > announcement for a Plasma x.y.2 per year with its own marketing name. > > ::snip:: > > > * Only have one release announcement on our website. We can call it > > Megarelease 6.XX like we did for Plasma 6/Gear 24.02 or find a better > name. > > I would avoid reusing Software Collection first because the name is quite > > technical and second because these was already used in the past. > > Sure, why not. This is not engineering I'm less opinionated about it. > Apart > from decoupling more between engineering effort and marketing > announcements > that is. > > Maybe reconsider the "Megarelease" term though... I've literally been > laughed > at for the use of that term outside of our community. Also, I think it was > a > fine term for a one off when moving on a major new version of Qt, but > it'll > get old quickly for the "business as usual". > I suggest that if we move to do any sort of more infrequent "mega releases" we call it KDE Community Software Release or similar. "KDE" is shorthand for our community, after all; why not spell it out. Valorie > > Again no strong opinion there, but I thought I'd mention what I've seen > around > me. > > Regards. > -- > Kevin Ottens, http://ervin.ipsquad.net > > enioka Haute Couture - proud supporting member of KDE > https://hc.enioka.com/en -- she/her. "Dwell on the beauty of life. Watch the stars, and see yourself running with them." - Marcus Aurelius
Re: kdewebkit status
On Sun, Apr 21, 2024 at 5:07 AM Ashark wrote: > Hello. > Hey Andrew, > > I have seen a bug that kdewebkit is failing to build (406342). I was > looking > why the person was building that module in the first place. > > Afaict, this module is not used in any project. Searching in repo-metadata > by > "kdewebkit" word, I see it is: > > Listed in `dependency-data-kf5-qt5` and in > `dependency-data-stable-kf5-qt5`, > without any dependency, and no any other project points to it as a > dependency. > > Listed in `kf5-frameworks.ksb` to be ignored: > ``` > module-set frameworks > repository kde-projects > use-modules frameworks > > #tag v5.75.0-rc1 > branch kf5 > ignore-modules kdewebkit kuserfeedback > end module-set > ``` > > and also listed in `kf6-frameworks.ksb` as ignored: > ``` > module-set frameworks > repository kde-projects > use-modules frameworks > ignore-modules kdelibs4support kdewebkit khtml kjsembed kmediaplayer > kinit > kjs kross kdesignerplugin kemoticons kxmlrpcclient > cmake-options -DBUILD_WITH_QT6=ON > end module-set > ``` > > The projects-invent/frameworks/kdewebkit/metadata.yaml contains the entry > ``` > repoactive: true > ``` > > Maybe this should be marked as `repoactive: false` and removed from ignore- > modules? > The repoactive flag mirrors the status of the repository on Gitlab (whether it is active or archived). As Frameworks as a compatibility promise, this repository will need to continue to limp around unfortunately until KF5 ceases to make releases. > > The project readme says that it is removed from kf6. > > > Cheers, Ben
kdewebkit status
Hello. I have seen a bug that kdewebkit is failing to build (406342). I was looking why the person was building that module in the first place. Afaict, this module is not used in any project. Searching in repo-metadata by "kdewebkit" word, I see it is: Listed in `dependency-data-kf5-qt5` and in `dependency-data-stable-kf5-qt5`, without any dependency, and no any other project points to it as a dependency. Listed in `kf5-frameworks.ksb` to be ignored: ``` module-set frameworks repository kde-projects use-modules frameworks #tag v5.75.0-rc1 branch kf5 ignore-modules kdewebkit kuserfeedback end module-set ``` and also listed in `kf6-frameworks.ksb` as ignored: ``` module-set frameworks repository kde-projects use-modules frameworks ignore-modules kdelibs4support kdewebkit khtml kjsembed kmediaplayer kinit kjs kross kdesignerplugin kemoticons kxmlrpcclient cmake-options -DBUILD_WITH_QT6=ON end module-set ``` The projects-invent/frameworks/kdewebkit/metadata.yaml contains the entry ``` repoactive: true ``` Maybe this should be marked as `repoactive: false` and removed from ignore- modules? The project readme says that it is removed from kf6.
Re: Proposal unify back our release schedules
i know quite a few have responded to this, but as the big warning on this, the fact that the three parts cant be released independently, is a big warning flag that a overhaul is needed of the overlapping architecture. i know this is a big issue, and the bigger the project, the bigger the workload. i saw someone was starting on a tool to graph architecture wise at https://invent.kde.org/sdk/codevis , its still in development, but i think this will highlight where the issue pinpoints are, break the cycles, and levelize everything. when stuff actually is decoupled, the frameworks would even be able to do staggered/piped deploys and the whole dev team would have less stress.. doing 3 releases a year or doing 12+ smaller ones, deploying from the base and going up, anything that depends on other parts will have to wait and since they still work against the last stable the friction will be less. i kept an eye on the mega release 6, and if that is viewed as a success i guess we got very different views on successes, from the mailing list it looked like at best organized chaos. On Fri, Apr 19, 2024 at 1:32 PM Carl Schwan wrote: > Hello Community, > > I know this might be a controversial idea, but I would like to propose > reunify > our release schedules. I feel like splitting our releases schedules between > Frameworks, Plasma and Gear is not working as well as we intended it to be > when > we split the releases schedules for Plasma 5. This is for multiple reasons: > > * We end up with 3 different products which are released at different > times but > are connected together. Apps and Plasma both need Framework, Plasma > needs some > packages from gear like kio-extra, Gear needs some package from Plasma > like > Breeze. Coordinating all these inter-groups dependencies is complex and > was one > the reason we had to do a megarelease for Plasma 6. Also for the end > user, one > product is a lot easier to understand. > here is a architecture bug list, the fact that there are circles like this is what needs to be dealt with before even thinking of feature development, its boring, and it will break stuff, but better take the bull by the horns and deal with it.. > * This results in very frequent releases which creates a lot of work for > distros > and talking with some distro maintainers they seems to agree that having > a big > releases every 4 months is better than having constantly a new minor or > major > release from either Framework, Gear or Plasma. > a stable release should support a known set say last 3 major releases for example. (this i due to the versioning scheme yy.mm counted as a major, then patches are the minors..) the released code used by downstream its the open source value chain.. 'master' is just work in progress until its released. distros themselves have the same issue with bad architecture, so to lessen their burden with dealing with broken stuff upstream they rather take a big release 'block' then a smaller one, its just a massive monolith they deploy then. big changes are always more risky then small ones.. problem is that features are more fun than doing maintenance on old stuff.. * We currently don't have a stable branch for Framework and it takes often > up to > one month for fixes to be deployed. The Framework releases is also not > in sync > with either Gear nor Plasma while these two modules heavily make use of > Framework > and contribute to Framework. > perfect candidate for automation.. deployment really should be automated, either by bots or other means. * We could have an unified LTS release including more than just Plasma. > This is > something that distros have been asking for some time already because > having > just Plasma receiving bug-fixes but not Framework nor the apps is not > that helpful. > i personally would prefer two release ways one feature release and one long term stable release, but this adds burden on the whole organization so i know its currently a utopia dream. mostly since KDE would have to do the Qt lts releases too since without a 'upstream' open source Qt LTS a KDE LTS is pretty useless since the dependency will have a lot faster churn than the dependency, its supposed to be the other way around.. the base is stable, the features and the churn happens a lot higher up in the structure. > * In term of promotion, it is very difficult to advertise the 3 releases > because > combined we have an important release of either Gear, Plasma or > Framework every > few weeks. This is too frequent and often while a combined announcement > would > have enough content to be published in a tech newspaper. When splitting > the content > accross 2 announcements (Gear and Plasma), we reduce the content per > announcement and this makes it less interesting for the journalists to > write > about us. This doesn't come from me, this is that some journalists > directly > told me. > this is not in my wheelhouse but i guess
Re: Proposal unify back our release schedules
Hello Carl, Promotion-wise it makes sense. We always have difficulty explaining and, hence, making the general public feel excited about the new versions of Plasma, as the concept of "desktop environment" is a concept that escapes (and bores) most people. But promoting a bunch of new apps, and a new set of configuration tools, and a new wallpaper and widgets is a much easier thing to do. Also new versions of things like Dolphin and Spectacle, which are closely associated with Plasma, are released with Gear, while System Monitor and Discover are released with Plasma. This makes zero sense to outsiders. Tl;DR: Sounds good to me. Cheers Paul -- Promotion & Communication www: https://kde.org Mastodon: https://floss.social/@kde Facebook: https://www.facebook.com/kde/ Twitter: https://twitter.com/kdecommunity LinkedIn: https://www.linkedin.com/company/kde
