On Montag, 24. Januar 2022 01:00:03 CET Friedrich W. H. Kossebau wrote: > in the past it was hard to find someone to fix things for KDE Frameworks on > Windows, and too often people not interested in Windows had instead to spend > their costly leisure time to solve problems, e.g. by debugging via CI runs. > > I do not think we can expect from every contributor/patch author they are > capable to understand and to solve things on all platforms. For one as this > does not scale, and even more when the platform is a proprietary one that > otherwise works against the mission of KDE and people rather avoid to have > to know about it.
That is not the expectation. The expectation is that you do not knowingly break any platform. This does not mean you have to be able to develop on all platforms and/or know about all platform specific details. It merely means it's your responsibility to ensure solutions for identified problems are found, e.g. by asking for help. This does not always work obviously, considering we have 7 failing modules on Qt5/Linux, 10 on Qt6/Linux, 12 on FreeBSD and 24 on Windows (and Android isn't even running any unit tests at all). There is however ongoing work to improve this, such as the upcoming pre- integration CI also on Windows or the discussion about stricter CI modes to prevent things from regressing again once fixed. Reviewing the list of frameworks built on Windows also makes sense, as noted elsewhere plasma-frameworks looks suspicious there for example. > So we need dedicated maintainer teams for each platform IMHO. And if that > team is empty, have to drop the official support for that platform, instead > of e.g. having it a "broken windows theory" thing on CI (pun intended). > > Given Linux (default, all the usual suspect contributors), FreeBSD (Tobias, > Adriaan), and Android (some other usual suspect contributors) are covered, > there is a reaction time the same day often, when help is needed with those. > Other than for Windows (and macOS once it makes it to CI). > > Who would be available as contact person for KF @ Windows, so could be > reliably called in to solve code issues appearing in new work or regressions > by external influences? Either by a to be created @teams tag or as highly > available individuals? > > If we do not have enough people who can provide at least, say, weekly work > on the Windows platform, I would propose to drop the official support, as > it is an annoying burden to those who have no stakes on that platform. > And also harms the reputation of the KF product, because being badly > maintained and thus partially broken makes it into the developer/user > experience on those platforms, which then is mapped onto the whole product > (rightfully), not just the support on that platform. Windows just happens to be a platform some of our applications have millions of downloads per year on, it might even be the platform used by most users of our software. We might not like it, but that's the reality we have to deal with. I don't think it's too much to ask everyone to pay attention to not breaking things there. I do appreciate your initiative to improve the situation even if I disagree with the suggested measures here. I would however suggest you try to approach this in a more constructive way, demands, deadlines and threats aren't getting us anywhere. Having submitted 18 MRs in the past days to fix KF unit tests (most of which I didn't break myself) makes me particularly unhappy having to face such demands today. Regards, Volker
signature.asc
Description: This is a digitally signed message part.