Define project scope
antoinealb opened this issue · 3 comments
For the bootloader release / deadline planned early January, what do we want exactly ? Do we want something "good enough" or do we want "The One Bootloader" ? There have been quite a lot of discussion recently about adding features that are IMHO out of the scope of a good enough bootloader. For example: Datagram retransmission on error (#27), asynchronous answer of the boards (#27), and reuse of the CAN datagram layer for other applications (#25).
All those features are not relevant for our use since the normal operation of the bus will rely on UAVCAN. At the same time the emphasis on quality and testing was reduced (#28), while I feel it is a much more important goal for this particular subsystem.
At this rate we won't be able to finish the bootloader in time, which will further delay the building of cool stuff. And I prefer writing cool stuff than protocol layers.
I'd like to see #25 in the first version of the bootloader, because changing the can-id format is not trivial once the boards are installed in the robot. The other changes can be addressed by a bootloader update. Plus it should be almost no effort to implement it.
I agree about #28, the test must always be updated with the code.
Ah and #24 (protocol version number) should probably be also in the version we flash on the robot.
I created a "1.0.0" issue tag that we should use to mark issues which must be resolved before shipping the bootloader in the robot. Issue without this tag can be fixed later without much trouble.