"Releases" bear little relation to the contents of this repository, and no relation to what the installer downloads

[ghalfacree]

The "Releases" section of this repository contains files which are not the same as those downloaded by the driver installation script; someone is directly editing "asset" files included with the very first release, from April 2021, without committing the code to the repository first, for some reason.

At the time of writing, the latest release was published yesterday. Opening the .tar.gz file gives you this in the Release/bin/ directory:

Note that this file only contains drivers up to kernel 5.10.63, meaning anyone running a newer kernel - like 5.10.92, the latest stable version released on Raspberry Pi OS at the time of writing - cannot install the drivers.

But if you use Arducam's own installer, it works. Why? Because it's pulling down a different archive containing files which have, for whatever reason, not been published to this repository.

The installer downloads this file, which is actually a manually-included asset bundled as part of the release tagged as "Arducam_pivariety_v4l2_v1.0" and which, according to GitHub, was released on the 2nd of April 2021.

Opening that gives you the following:

Drivers all the way up to kernel version 5.10.92, which was added to the archive on the 21st of January 2022 - more than nine months after the release was tagged on GitHub.

I'm not sure what the reason is for editing tagged release files directly without a commit, but it's certainly a cause for confusion - and prevents anyone from easily finding the driver files themselves, or from using the repository to track changes and updates.

I would also be interested in knowing exactly where the driver "asset" file is being generated from: only the older driver files are present in the Release/bin directory of this repository.

[glddiv]

Hi @ghalfacree

I'm not sure what the reason is for editing tagged release files directly without a commit, but it's certainly a cause for confusion - and prevents anyone from easily finding the driver files themselves, or from using the repository to track changes and updates

We don't want to have binaries in the code repository, which makes the repository very large. For multiple versions of the kernel driver, their source code is the same, in order not to increase the size of the code base, we choose to directly update the files in the release.

I would also be interested in knowing exactly where the driver "asset" file is being generated from: only the older driver files are present in the Release/bin directory of this repository.

For the same reason, we don't want to have binaries in the code repository, which makes the repository very large.

[JoeAYeung]

@glddiv Will the kernel driver be merged into the Linux kernel in the foreseeable future? It's a lot of work for you to maintain different versions of it!!

[ghalfacree]

For multiple versions of the kernel driver, their source code is the same, in order not to increase the size of the code base, we choose to directly update the files in the release.

The correct way of doing this would be to make a new release each time but include the binaries as an asset - exactly like you're doing now, but without replacing earlier versions. That way, users can see if there's a new release, you can include release notes, it's easy to see if your kernel version is supported, if your kernel version isn't supported you can receive an automatic notification when it is, and if there's a bug in the new version it's easy to roll back to the older version.

None of that is possible with the way you're doing things now.

We don't want to have binaries in the code repository, which makes the repository very large.

The compressed asset file you are currently distributing by editing the very first release is 238kB in total; uncompressed, every single driver version you supply is 767kB.

You're already including 374kB of binaries - builds for kernel versions 5.10.17, 5.10.52, 5.10.60, 5.10.63 - in the repository; what is your objection to including another 393kB?

Either have no binaries at all, and include the full source code and a build script for creating them, or have all the binaries. Having a seemingly-randomly-selected half of the binaries in the repository is a really odd choice.

Personally, I think keeping the repository purely for source code but ensuring you have valid build instructions is the best approach - combined with, as above, ensuring a fresh copy of the binaries you generate yourself is included with every release as a bundled asset. Best of both worlds, then.