On Thu, Jun 17, 2021 at 7:26 AM Avamander <avaman...@gmail.com> wrote:
> Hi, > Hi there, > > This is indeed an issue that has occurred previously, and actually > I've written to you, Ben, once before about this. Now I'm asking again, why > is it necessary to email *FIVE* mailing lists for issues that are > primarily solved by a much much smaller subgroup of people? Maybe send it > to a few C++ lists as well, maybe someone'll jump out and fix the CI 🤪 > According to my email archives we've not previously corresponded - and the name "Avamander" is certainly new to me. The five lists in question were chosen deliberately for the following reasons: 1) kdeconn...@kde.org as the matter related to KDE Connect 2) kdevelop-de...@kde.org as the matter related to KDevelop 3) kde-frameworks-de...@kde.org as the email explained why Frameworks had experienced a substantial number of Windows CI failures lately 4) kde-devel@kde.org as the email explained to various Extragear projects why they had experienced Windows CI failures as well 5) sysad...@kde.org as the matter related to our infrastructure > On a very related topic, for the third time, send the kdeconnect CI status > emails to the actual developers and contributors for whom they are > actionable, not the entire kdeconnect mailing list. It's just noise for the > majority of non-code contributors, non-code contributors that might be able > to help with support questions but who are very likely ignoring the list > due to horrifically bad SNR. > Please direct your complaints regarding the content and moderation of the kdeconn...@kde.org to the list administrators - kdeconnect-ow...@kde.org - in the first instance or raise a thread on that mailing list. With regards to the CI status emails, these were setup at the request of the KDE Connect developers in https://phabricator.kde.org/D13794 > > > Have an extra day, > Avamander > Regards, Ben > > On Wed, Jun 16, 2021 at 9:29 PM Ben Cooksley <bcooks...@kde.org> wrote: > >> Hi all, >> >> The following is notice that I intend to withdraw CI services from the >> following two KDE projects due to faults in their code or build system >> which are having a significant adverse impact on the CI system and >> negatively impacting on other projects: >> >> - KDevelop >> - KDE Connect >> >> This withdrawal will be applied to all platforms. >> >> In the case of KDevelop, it has a series of unit tests which on FreeBSD >> cause gdb to hang and consume an entire CPU core indefinitely. This slows >> down builds for all other projects using that CI server, and also prevents >> KWin tests from proceeding - completely blocking it's jobs. This fault is >> in the debuggee_slow family of tests. >> >> As this issue has persisted for some time now despite being mentioned, I >> require that the family of tests in question be disabled across all >> platforms. >> >> In the case of KDE Connect, as part of it's configure process it runs an >> external command that results in dbus-daemon being launched. This process >> persists following the build and would only be cleaned up by our tooling >> that runs tests. Should the compilation fail (as it does currently) it will >> result in the CI builder being broken - which is why we have had so many >> Windows builds fail lately. >> >> As this is an issue that has occurred previously, I require that the >> configure time check which is launching dbus-daemon to be expunged from KDE >> Connect. >> >> As a reminder to all projects, running commands that interact with >> dbus-daemon or kdeinit is not permitted during configure or build time. >> >> Regards, >> Ben Cooksley >> KDE Sysadmin >> >
