Import LXD changes (last batch before the re-licensing) #300
Conversation
This commit does the following: 1. Adds the 'revive' linter and appropriate rule configuration. I have added all of the rules that I thought would be useful. There are many more rules that can be included (please see https://github.com/ - mgechev/revive/blob/2a1701aadbedfcc175cb92836a51407bec382652/ - RULES_DESCRIPTIONS.md#description-of-available-rules). 2. Sets 'exclude-use-default' under issues. This is required for golangci-lint to stop ignoring errors from revive's 'exported' rule. However, it also has the side effect that the default excludes for default linters are no longer set. This means we need to set some excluded functions in the configuration of 'errcheck'. Signed-off-by: Mark Laing <[email protected]>
…ts from switch. These lint errors were previously ignored by default but are now displaying because of the change to the .golangci.yml file which set 'exclude-use-default' to false. Signed-off-by: Mark Laing <[email protected]>
There are thousands of revive rule errors. To avoid having to fix all of these immediately we can invoke golangci-lint using the '--new' and pass in a revision. In this script the revision is determined by the most recent commit in the target branch, defaulting to 'main' for 'GITHUB_BASE_REF' when running in CI. Signed-off-by: Mark Laing <[email protected]>
This will now be invoked via 'run-parts', which runs all of the scripts under test/lint (including our new 'golangci.sh' script). Signed-off-by: Mark Laing <[email protected]>
…ecArgs in ExecInstance Signed-off-by: Thomas Parrott <[email protected]>
…socket if established in ExecInstance Signed-off-by: Thomas Parrott <[email protected]>
…err output if writer(s) not supplied in ExecInstance Fixes #12636 Signed-off-by: Thomas Parrott <[email protected]>
Signed-off-by: Thomas Parrott <[email protected]>
…reate pools You can now automatically create the required file system and pools when setting up a CephFS storage pool. Signed-off-by: Ruth Fuchss <[email protected]>
|
So... Canonical decided to completely take over LXD and since it wasn't enough they also decided to kill Incus or any other fork that could benefit from Canonical's commits but be community driven. @stgraber what does this re-licensing mean for the future of this project? |
|
It just means we can't look at anything going into the LXD repository and so will have to duplicate work on fixing bugs or introducing features our users want. That's mostly a waste of both projects' time and will cause the two to diverge faster than would have otherwise happened. But it's not going to be the end of Incus, far from it. This latest move has attracted a fair amount of LXD users and contributors to jump ship and come to Incus instead. So if anything we're going to have a stronger project out of it. |
I'm all for jumping ship, no doubts there, better yet once Debian starts packing Incus, I guess around Debian 13. With that said, yes, this is a waste of time, and more importantly funding. Canonical has big money to develop LXD and now I hope you and the other amazing people that will spend a TON of time improving Incus are properly funded / payed for their time. Btw, only now I found your post about it. https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/ Thank you for all the great work. |
Well, the LXD team is pretty well funded but a lot of those folks don't really work on LXD itself. These days there are only really 3 people working full time on LXD itself, the rest are part-time at best. Of those 3, 2 joined within the past 6 months so are still getting up to speed. Whereas on our side, I'm working on it full-time and we have all the original LXD developers on the team as part-time maintainers. So which of the two is better staffed these days is up for debate ;) |
Those are the remaining commits from the LXD repository prior to its re-licensing under the incompatible AGPLv3 license, no further changes will be imported from LXD.