Post-MegaRelease projects

[Konstantin Kharlamov]

On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote:
> On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov
> <Hi-Angel at yandex.ru> wrote:
> > On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote:
> > > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela <nospam at vuorela.dk>
> > > wrote:
> > > > On 2024-02-22, Nate Graham <nate at kde.org> wrote:
> > > > > I've started pondering post-megarelease projects. We've spent
> > > > so long on 
> > > > > porting and bugfixing that I think it might be useful to
> > > > shift gears to 
> > > > > feature work, and I'd like to brainstorm potential large-
> > > > scale projects 
> > > > > and gauge the level of interest in putting resources into
> > > > them soon.
> > > > 
> > > > A bit more from the devops end that I'd love to see people
> > > > tackle:
> > > > 
> > > >  - Ensure frameworks and app unit tests interacting with
> > > > windows can run
> > > >    on Windows.
> > > >    More details: The following fails on our windows CI
> > > >  
> > > >  https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp
> > > >    I find it weird that we are spending resources on putting
> > > > things in
> > > >    the windows store and making apps available on windows, but
> > > > we can't
> > > >    actually have passing tests in our CI.
> > > > 
> > > 
> > > 
> > > This unfortunately will not be easy to solve. 
> > > 
> > > One of the key things that we've learned out of doing CI, as has
> > > been showcased by FreeBSD in particular, is that the builders
> > > need to be ephemeral - that is only around for the build in
> > > question that is being run.
> > > We're currently accomplishing this by using containers - via
> > > Podman (for Linux/Android/FreeBSD) and Docker (for Windows).
> > > 
> > > Containers also offer us the advantage of allowing people to
> > > easily reproduce the CI environment on their local system without
> > > too much trouble.
> > > 
> > > For Windows however, Microsoft has limited the container stack to
> > > not allow anything GUI related to work. The underlying libraries
> > > may be there, but the equivalent display server components are
> > > not operational.
> > > 
> > > To complicate things further, on Windows certain permissions are
> > > restricted to the interactive console and are not possible to do
> > > as either a scheduled task or as a system service.
> > > Usage of existing Windows automation frameworks such as
> > > Powershell Remoting or SSH will therefore not work if we want
> > > things to perfectly replicate a end user environment - because
> > > those will run the command(s) as part of a non-interactive
> > > session (even if the user we connect as is the same one logged in
> > > on the desktop console).
> > 
> > 
> > Idk if it's a silly question, but… If Windows native containers
> > have so many restrictions, why not just use Linux containers with
> > WINE inside?
> > 
> 
> 
> Because Wine is not Windows either, and there could be subtle
> differences in how things run / interact with the system.
> Plus some of our software would like to test certain system level
> infrastructure (like say KDE Connect).

Out of curiosity, what does this infrastructure include? I thought KDE
connect only uses network sockets and system tray.

> Plus, we have to have native Windows to compile things anyway as we
> need to use MSVC (otherwise you have no Qt Web Engine support, as
> that cannot be built with MingW)

But I presume it can be built with Clang? In particular, Google Chrome
on Windows is being built with Clang — and Web Engine is basically a
fork of Chromium.

> (and you cannot really mix MingW / MSVC binaries due to incompatible
> compiler ABIs for C++ code)

Well, if for testing purposes Qt was pre-built with Clang, I guess
there won't be any ABI issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20240224/90fea988/attachment-0001.htm>