Ihor Dutchak

> A bunch of easy-to-review commits is better than huge commits > Each of them would have made sense without the others To my experience - that's a good reason...

[This](https://github.com/libusb/libusb/pull/1460/commits/31781b7bd93c86a1b3967c8d1d9014132df8a0a0) commit, apparently introduces an issue: ``` C:\projects\libusb\libusb\descriptor.c(276,24): error C2220: the following warning is treated as an error [C:\projects\libusb\msvc\libusb_static.vcxproj] ifp->extra_length = len; ^ 2>C:\projects\libusb\libusb\descriptor.c(276,24): warning C4244: '=': conversion from 'intptr_t'...

> MSBuild might be not supported on Github Actions HIDAPI [successfully](https://github.com/libusb/hidapi/blob/7011fa98af2dde00c298105735e470de800288c7/.github/workflows/builds.yml#L329) using it. I believe the limitation is that not all versions of Visual Studio are pre-installed on self-hosted runners....

https://github.com/actions/runner-images/blob/main/images/windows/Windows2019-Readme.md MSVC 2019 is availabel if [windows-2019](https://github.com/actions/runner-images#available-images) is used - that's something. But I guess that's it :) Long-term we could use GithubActions to test latest available MSVC and AppVeyour...

It depends. One you can use MSVC build toolchain for free. Visual Studio IDE has a free license which is not free for corpodate usage. There is also a cost...

The CI won't start unti the conflict is resolved. > Eventually I'd like to see AppVeyor going away (for sure after 1.0.27 release, and most likely after 1.0.28 release). Then...

> What if we at least remove VS2019 & VS2022 debug (where we don't care about artifacts) from AppVeyor? Sound fine to me.

> Though I did not actually improve error checking... I don't see any actual benefin otherwise. Is there? Unless you're planning more changes on top of it.

I think we will not be able to get a single `.clang-format` for the entire project. At least not at the beginning. We need to figure out if it is...

Second thing: I think we should come up with a `.clang-format`, which, when applied - produces (reasonably) the smallest diff in the existing code.