https://bugs.kde.org/show_bug.cgi?id=444138
--- Comment #8 from Dominik Kummer <ad...@arkades.org> --- @Aleix without cron mirroring the fork I'd rather add and fetch a remote "upstream", rebase upstream/master and push origin master. The thing is, if an organizational vector touches several integral kde projects (in a modular way of course) and probably takes lots of local research and testing, I think its better to have relevant up-to-date forks, which keeps the concept/usecase/showcase isolated first. Thats the case if a feature is complex, and one has no interest in discussing/arguing every single merge or something. My aim is to show usecases of rdf, nepomuk/baloo, akonadi, kraft, calligra/kile, freecad (bim/ifc), kplan inside a custom arch distro. If the usecase/concept is actually useful I could propose/file merge requests upstream to kde. So I am currently planning a continous integration across arch build system, kdesrc-build and custom distro build system, containerized testing with buildah/podman/nspawn. Mirroring the fork's master just seemed to be useful, to get rid of the local upstream rebase. -- You are receiving this mail because: You are watching all bug changes.
