Maintainers of KDE Frameworks for the Windows platform?
Ben Cooksley
bcooksley at kde.org
Mon Jan 24 10:23:19 GMT 2022
On Mon, Jan 24, 2022 at 10:48 PM Christoph Cullmann (cullmann.io) <
christoph at cullmann.io> wrote:
> On 2022-01-24 01:00, Friedrich W. H. Kossebau wrote:
> > Hi,
> >
> > 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.
> >
> > 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.
>
> I don't agree with that mindset.
>
> Naturally, as you point out in your other mail,
> the unit tests must be fixed.
>
> But beside that, I see Windows like any other platform,
> you need to ensure your changes don't kill it.
>
> It is not acceptable to commit stuff that breaks the e.g. FreeBSD
> CI, the same rule can be there for Windows, too.
>
> If you need help, you can ping people like me for Windows or we could
> create
> some @teams/windows or whatever.
>
> Beside that, I think in most cases, our code is on a level that doesn't
> really have that much operating specific parts.
>
I concur with Christoph's points here.
>
> There are special cases like baloo and Co., I actually would propose to
> not support such stuff on Windows (or non Linux) at all,
> not sure if it should be a Framework at all in that case.
>
A comprehensive list of what we currently support some form of CI for can
be found at
https://invent.kde.org/sysadmin/ci-management/-/blob/master/seeds/frameworks-latest.yml
Windows CI on Gitlab is not too far away - Frameworks is actually ready to
go as it were I just need a chance to try to run the seed jobs.
Alas other matters keep getting in the way (both within and outside of KDE)
>
> Greetings
> Christoph
>
Cheers,
Ben
>
> --
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20220124/6c0d3142/attachment.htm>
More information about the Kde-frameworks-devel
mailing list