20180808 Weekly Meeting
General:
HamishW:
- Lorenz - per-message versioning follow up.
- File formats - should they be part of MAVLink?
JamesP
- Devguide / webpage branding and linking
- Governance and merge rules (mavlink and pymavlink).
-
@JamesP Presented case that mavlink.io needs to be unbiased/treat autopilots & GCS equally.
-
@HamishW Project agree/aware of the problem. Presented in-progress demo of new project header bar that will address some of the concerns (Make header "pointer to generic resources").
-
@JamesP Suggested adding ArduPilot with equal billing in the sidebar below the Dronecode links.
-
@HamishW "just not got that far yet to addressing sidebar in demo"
-
@Lorenz Better to remove all links/preferences in sidebar - that way there is no question of bias or of how to extend in future. All agreed.
-
AI @HamishW to create PR "in coming weeks" with proposed new structure and share with community for review. EDITED (Done) See #105
- @General: We know there is a bunch of cruft in common.xml that we'd all like cleaned (unused and "bypassed" messages). Proposal is to review and remove all this in a single breaking release, with good documentation/release notes and communication to the community - and iterate the minor release number.
- MAVLink users will have to start checking the release version number for potential breaks.
- But at least we'll have a clearer model for breaking changes, and a good place where people can check.
- @JamesP indicated he thought it sane but would discuss with the community. Pointed out that change from ArduPilotMega.xml to ArduPilot.xml might be a good point for coordinating the change.
AI @JamesP - to check if ArduPilot community are amenable to helping define the cruft and this kind of release approach.
AI (Lorenz): Send meeting members issue number with proposal for message versioning (please update if needed to clarify final proposal)
- Discussion about what should be in common.xml vs dialects.
- General principle is that common should have things that are likely to be generally useful (until they have proved not to be or are superseded).
- Dialects should have things for which really are odd ideas, or for which no agreement can be reached.
- General point, also applies to protocols
- they should aim to be shared rather than siloed.
- Desirable to converge towards single microservice definitions. Specific ones worth consolidating are Mission, Parameters, Fence, and approach for "ADSB/FLARM"-like systems. For a time GCS will have to support multiple, but over time will be able to work with just one.
- Try to avoid heavyweight process
- Do not need every single community member to agree every change, but signoff for breaking changes expected from major stakeholders.
- Decisions made on technical merit as presented by stakeholders, and go with majority if deadlocked.
@Lorenz raised discussion on whether the toolchain should be improved.
- Current language support is not consistently maintained.
- Resources needed, and are likely to cover from companies that care about standardization (rather than GCS). This includes SDK developers.
- Many generator systems like this use template engines, resulting in code that is easier to maintain and extend.
- It is "a bit weird for users" that the generator isn't in the mavlink repo but that isn't essential to deal with.
@James
- ArduPilot have resource to maintain Pymavlink.
- But possibly not to extend.
AI @Lorenz to start off an RFC so that that others can engage with the question on technical merits.
@HamishW raised point from some members that it would be "nice if XML messages were in own repo". Discussion came down to "Possibly, but not a priority".
@HamishW Investigate why mavlink.io common.xml slow to load/render EDIT: Done in #103
@James Follow up on #861 Local and body frames - ArduPilot doing some work in this area and may have opinions.
@Lorenz send JamesP issue/information about PR to avoid creating multiple instances of SHA256 table that needs to be pushed into generators. @James to discuss with Tridge.
[Discussion] [Points that need further discussion]
[Discussion]
- Overview of Call 1
- versioning discussion continued
- idea raised to split and version the microservices separately (param protocol, mission, etc)
- overall message version (eg common) would then reference versioning of each included protocol
[Points that need further discussion]