E1.33 controller #43
E1.33 controller #43
Conversation
…nto master-resync
…esync Master resync
…-mk2-serial-id Track Eurolite MK2 by actual serial number where available
Bumps [actions/setup-node](https://github.com/actions/setup-node) from 3 to 4. - [Release notes](https://github.com/actions/setup-node/releases) - [Commits](actions/setup-node@v3...v4) --- updated-dependencies: - dependency-name: actions/setup-node dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 3 to 4. - [Release notes](https://github.com/actions/download-artifact/releases) - [Commits](actions/download-artifact@v3...v4) --- updated-dependencies: - dependency-name: actions/download-artifact dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
…ng-latest Update some copyright years
…o master-resync
|
Thanks for the other reviews @kripton! I'm pleased to say I've now got a basic E1.33 controller working (currently independent of the main olad). I've not tidied and pushed up all the code yet. In terms of trying to reduce this giant changeset, as mentioned, most of the commits add a new PDU each (across three files), do you think there's an optimal number of files/size of commit to split it into for review to keep it manageable? For example here's the BrokerClientEntryPDU set of three (the PDUs vary in complexity a bit, but they're mostly broadly the same): I'll need to cherry-pick to get them into master without just queuing them up behind the existing LLRP stuff, but they should work fine standalone functionally... |
…ng-latest Ignore more minified files that might contain spelling false positives
Co-authored-by: Peter Newman <[email protected]>
…dependabot/github_actions/actions/upload-artifact-4+download-artifact-4 Bump actions/upload-artifact and actions/download-artifact from 3 to 4
…P-fix-gcovr-parse-bug Workaround gcovr parse race condition bug
Add support for the IPv6 data type to the RDM messaging
(cherry picked from commit 3d752e7)
…erry-pick E1.33 cherry pick number 6
…nto e1.33-controller
(cherry picked from commit 71378c9)
…more of it (cherry picked from commit f2343ce)
(cherry picked from commit 8db5131)
(cherry picked from commit 05404c7)
(cherry picked from commit 2c2fdc7)
(cherry picked from commit ebe7f20)
(cherry picked from commit 44ad498)
(cherry picked from commit ed8d532)
(cherry picked from commit 2d5280c)
(cherry picked from commit 672ca47)
(cherry picked from commit 720bb24)
(cherry picked from commit 3d070a6)
(cherry picked from commit bc81275)
(cherry picked from commit 54d2743)
…erry-pick E1.33 cherry pick vii
…nto e1.33-controller
Please don't actually start reviewing this @kripton , but if you fancy taking a look at it in due course, I was going to break it down a bit to reduce the overall changes of this and https://github.com/OpenLightingProject/ola/pull/1612/files .
Most of the commits add a new PDU each (across three files), do you think there's an optimal number of files/size of commit to split it into for review?
I'll need to cherry-pick to get them into master without just queuing them up behind the existing LLRP stuff, but they should work fine standalone functionally...