[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Post-MegaRelease projects
From: Ben Cooksley <bcooksley () kde ! org>
Date: 2024-02-24 9:16:56
Message-ID: CA+XidOGs4KxPpRm8=n-_MJhgYfCBD_176cAsNW372AY0y39k=g () mail ! gmail ! com
[Download RAW message or body]
On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov <Hi-Angel@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@vuorela.dk> wrote:
>
> On 2024-02-22, Nate Graham <nate@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).
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)
(and you cannot really mix MingW / MSVC binaries due to incompatible
compiler ABIs for C++ code)
Cheers,
Ben
[Attachment #3 (text/html)]
<div dir="ltr"><div dir="ltr">On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov \
<<a href="mailto:Hi-Angel@yandex.ru">Hi-Angel@yandex.ru</a>> \
wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div class="msg-7499273896793515902"><div><div>On \
Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote:</div><blockquote type="cite" \
style="margin:0px 0px 0px 0.8ex;border-left:2px solid \
rgb(114,159,207);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Fri, Feb 23, 2024 \
at 11:12 PM Sune Vuorela <<a href="mailto:nospam@vuorela.dk" \
target="_blank">nospam@vuorela.dk</a>> wrote:<br></div><div \
class="gmail_quote"><blockquote type="cite" style="margin:0px 0px 0px \
0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div>On 2024-02-22, \
Nate Graham <<a href="mailto:nate@kde.org" target="_blank">nate@kde.org</a>> \
wrote:<br>> I've started pondering post-megarelease projects. We've spent \
so long on <br>> porting and bugfixing that I think it might be useful to shift \
gears to <br>> feature work, and I'd like to brainstorm potential large-scale \
projects <br>> and gauge the level of interest in putting resources into them \
soon.<br></div><div><br>A bit more from the devops end that I'd love to see \
people tackle:<br></div><div><br> - Ensure frameworks and app unit tests interacting \
with windows can run<br> on Windows.<br> More details: The following fails on \
our windows CI<br> <a \
href="https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp" \
rel="noreferrer" target="_blank">https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp</a><br> \
I find it weird that we are spending resources on putting things in<br> the \
windows store and making apps available on windows, but we can't<br> actually \
have passing tests in our CI.<br></div><br></blockquote><div><br></div><div>This \
unfortunately will not be easy to solve. </div><div><br></div><div>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.</div><div>We're currently accomplishing this \
by using containers - via Podman (for Linux/Android/FreeBSD) and Docker (for \
Windows).<br></div><div><br></div><div>Containers also offer us the advantage of \
allowing people to easily reproduce the CI environment on their local system without \
too much trouble.</div><div><br></div><div>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.</div><div><div><br></div><div>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.</div><div><div>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).</div></div></div></div></div></blockquote><div><br></div><div>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?</div></div></div></blockquote><div><br></div><div>Because Wine is not Windows \
either, and there could be subtle differences in how things run / interact with the \
system.</div><div>Plus some of our software would like to test certain system level \
infrastructure (like say KDE Connect).</div><div><br></div><div>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)</div><div>(and you cannot \
really mix MingW / MSVC binaries due to incompatible compiler ABIs for C++ \
code)</div><div><br></div><div>Cheers,</div><div>Ben</div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic