[riot-notifications] [RIOT-OS/RIOT] drivers/bme680: replace pkg with module (#15738)
notifications at github.com
Fri Jan 15 14:14:40 CET 2021
I think it would be helpful to split the discussion into two topics:
1. Should we allow replacing drives implemented as package with custom drivers?
2. The technical discussion of the implementations
Right now this PR has not yet received technical review. (Not even internal review, as we decided for transparency to do provide review publicly via the normal PR process.) But this technical is the very process which results in technically improving a PR. However, it is strongly demotivating for me to review this PR and I suppose it is demotivating for @Jnae to improve this PR when there seems to be fundamental non-technical opposition against replacing packages with internal drivers.
So, let's please for now wait with the technical review and first reach an agreement on whether a custom driver is acceptable when a pkg with the same features is already present. If, and only if, we agree that this is the case, it makes IMO sense to engage in the technical review. And then we can do a fair technical comparison once this PR has matured due to the review process.
Jumping in the non-technical discussion: IMHO, we shouldn't favor packages over modules just because we don't have to maintain external code. First, we have a lot of code in RIOT that provides the same features that external code could provide. But still, we have a custom network stack, a custom scheduler, custom IPC mechanism, etc. Those were created because we choose to implement things differently, approach problems differently, and do different trade-offs. Second, packages also need to be maintained. If you look at the recently removed [emb6](https://github.com/hso-esk/emb6) network stack - the effort to maintain that pkg compared to our GNRC would have certainly be less, but still emb6 remained unmaintained and was dropped for that reason while GNRC is well maintained. So IMO it is not only about the effort to maintain, but also (and even more importantly) about whether we have people willing to do the work.
We (ComSys) have decided on the BME680 sensor for our testbed nodes. Hence, we have interest in having the best possible support of the device in RIOT. I currently cannot see any legal path forward for friction-less support of gas quality measurement based on Bosch's code due to license issues. In the end, I see no alternative to providing a custom implementation of that via reverse engineering the underlying conversion function of the proprietary Bosch library. But that would best be integrated into a single driver module.
Finally, I don't see that the package and the module are mutually exclusive. While there is interest in having both, we could have the pkg and add a bme680 driver as module, if and when our usual technical review process concludes the PR is ready. If interest in or maintenance of one of the driver implementation ceases, we could simply drop it in favor of the other.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications