-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release HOWTO and supporting Makefile tasks. #102
Conversation
Test PASSed. |
[`existing`](spec/yaml/swiftnav/sbp) messages. | ||
|
||
1. Add a message definition to the approprate package, or create a new | ||
one if needed. The message ID needs to be unique. A message should |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should reference a section "Message Guidelines". I have a few more things that would go under guidelines, I'll follow up in another comment.
I think there should be a section for "Message Guidelines". I'd suggest the following:
|
Also we need to have a policy around ID assignment, but its more work. Its not just arbitrary because you have to consider the implicit groupings created when using a message mask. |
The message mask system is cute, but I wonder how scaleable it really is, and how much overhead it would be to support arbitrary lists of desired messages - my guess is, that wouldn't be significant hit to performance or resource usage. |
Agree, I would be happy to move to some kind of more granular system. The thing I have been wondering about with a whitelist type system is if you want to specify that you want e.g. all messages or all of a certain kind of message. You could put a long list in the settings but it would always need to be updated. Seems like there is a lot of potential for people to get tripped up. |
I think a whitelist would be pretty intuitive - if you want a particular message, you have to add it to the list. Other way would be groups of messages but you could probably implement that on top of a whitelist. |
Test PASSed. |
0. Updates Makefile to handle some RELEASE boilerplate. 1. HOWTO: Document some relevant procedures around releasing libraries and adding messages. Closes swift-nav#78. /cc @mfine @fnoble @denniszollo
Test PASSed. |
Release HOWTO and supporting Makefile tasks.
and adding messages.
Closes #78.
/cc @mfine @fnoble @denniszollo @henryhallam