Post-MegaRelease projects

[Konstantin Kharlamov]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20240224/ad281d5c/attachment.htm>