[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-community
Subject: Re: Post-MegaRelease projects
From: Konstantin Kharlamov <Hi-Angel () yandex ! ru>
Date: 2024-02-24 9:27:16
Message-ID: 6715ee546860f81b8306c77f11924b976673f3b1.camel () yandex ! ru
[Download RAW message or body]
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@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).
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.
[Attachment #3 (text/html)]
<html><head><style>pre,code,address {
margin: 0px;
}
h1,h2,h3,h4,h5,h6 {
margin-top: 0.2em;
margin-bottom: 0.2em;
}
ol,ul {
margin-top: 0em;
margin-bottom: 0em;
}
blockquote {
margin-top: 0em;
margin-bottom: 0em;
}
</style></head><body><div>On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley \
wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf \
solid;padding-left:1ex"><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 type="cite" style="margin:0 0 0 .8ex; border-left:2px \
#729fcf solid;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:0 0 0 .8ex; border-left:2px #729fcf solid;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:0 0 0 \
.8ex; border-left:2px #729fcf solid;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><div><br></div></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><br></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></div></blockquote><div><br></div><div>Out of curiosity, what \
does this infrastructure include? I thought KDE connect only uses network sockets and \
system tray.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; \
border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div \
class="gmail_quote"><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></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; \
border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div \
class="gmail_quote"><div>(and you cannot really mix MingW / MSVC binaries due to \
incompatible compiler ABIs for C++ \
code)</div></div></div></blockquote><div><br></div><div>Well, if for testing purposes \
Qt was pre-built with Clang, I guess there won't be any ABI \
issues.</div><div><span></span></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic