The only time this held, vaguely to my recollection, true was prior to Incus 0.4 where both were cherry picking from each other but neither were upstream of each other
It's very very different between the UI and Incus itself :)
The Incus teams are low level system engineers who develop in Go or C.
The UI is a pile of typescript which none of us really want to understand/touch any more than strictly needed.
The Incus UI is a soft fork (really just a small overlay) on top of the LXD UI to adjust for the API differences between LXD and Incus and for fixing the few big gripes we had with the LXD UI. Because both projects are under the same license, we can actually just follow what happen in LXD UI and pull in code from it.
Incus is a very different beast. The whole reason the project had to be started is because of Canonical's series of changes which eventually led to a re-licensing of LXD to AGPLv3. With Incus remaining Apache 2.0, none of us can even look at the LXD code without risking being "tainted". We cannot import any code from LXD since that license change and we never have. However LXD has no problem with importing Apache 2.0 code into an AGPLv3 codebase, which they have quite actively been doing.
In short Incus is a hard fork of LXD, we don't look at any LXD code or even at their issues or release announcements (mostly because it's not useful for those two). That means that everything that happened in Incus since December 2023 has been completely independent of LXD.
The Incus UI is a soft fork of the LXD UI, it's rebased every time they push a new version out and our goal is to keep the delta as small as possible as it's something we want to spend as little time on as we possibly can. It's also why we always package it as "incus-ui-canonical" to make it very clear as to what it is.
There are also other UIs out there that could be used, sadly last I checked none came close to the feature coverage of the LXD UI or they had dependency on external components (database, active web servers, ...) whereas what we want is a UI that's just a static javascript bundle which then hits our REST API like any other client.
> I mean sure, it's the UI component only, and not on the lxc repo but the Zabbly one, and maybe they treat things widely differently depending.
This one is fair since Incus and Zabbly have had no desire to reimplement a web UI, they've instead opted to leave that to the community resulting in LXConsole for example.
Zabbly, for additional context, is Stephane Graber's company that he set up as a consultant service for Linux and Linux Container (both in terms of the Linux Container organization and the LXC project)
EDIT: I read this part to suggest that former LXD team members that are now on the Incus team potentially have the same mindset, if this is wrong, please correct me.
> And I swear I had a similar experience with regards to some other incus issues where there was a similar response about changes.
So far from my two years of interaction (both as a lurker and commenter) on the forums and purveyor on the issue tracker, I've yet to see anything that resembles treating Canonical LXD as any form of upstream especially since the split.
Will check this out! I knew there was a group who had a version working, but it wasn't upstreamed and last I check was still stuck at .NET 5. While I would like to migrate from Debian to FreeBSD, probably won't get management to okay that with current services, but future one, maybe!
This has been one personal pet peeve with the documentation surrounding Incus.
As a stack, Incus has been exceptional, it has largely replaced Proxmox and Podman Quadlets for me. For context, I homelab so I cannot generalize my claim to SMB or enterprise.
But the documentation has been very end user oriented, information regarding specifics like seccomp as you mentioned are only discoverable with the search bar and that leads to various disparate locations; and that also isn't taking into account that some of the more nitty gritty information isn't on the Incus portion of linuxcontainers.org, see the LXC Security page for example: https://linuxcontainers.org/lxc/security/
Yes, Xen was big on paravirtualisation but started supporting the other kinds pretty soon, too. (At least they were supported around 2009-2012, when I was working on XenServer.)
The only time this held, vaguely to my recollection, true was prior to Incus 0.4 where both were cherry picking from each other but neither were upstream of each other