@dali99, thanks for the review. I believe I've applied the needed changes.

Commits need to be squshed, PR title needs updating.

bacnet-stack: init at 1.0.0 should be the only commit

Should be good to go.

For future reference, should I always keep everything in a single commit during the review process? I figured that it would make reviewing easier if I maintained the history until the review was done. I am aware that PRs should be squashed to a single commit before merging, of course.

I'm also on the fence about it. I personally would like to avoid force pushes until the end, since it's much easier as you say to see the diffs, not to mention that force pushing has a tendency to break the links in the notifications.

But that's not what I usually see people doing.

Anything remaining before we can merge?

no we just need someone with mergeaccess to look at it
@jonringer

Please follow CONTRIBUTING.md and manual#submitting-changes-making-patches and squash the fix-up commits.

This can be done without git rebase -i by doing:

git reset HEAD~1                    # move fix-up commits into unstaged
git add -- pkgs/                    # move changes into staged
git commit --amend --no-edit        # add changes to previous commit
git push ... ... --force            # modify current PR branch

However, git rebase -i is a more powerful alternative, I created a small video demonstrating it's use here. A more indepth text tutorial can be found here

@jonringer, For future reference, should I always keep everything in a single commit during the review process? I figured that it would make reviewing easier if I maintained the history until the review was done. I am aware that PRs should be squashed to a single commit before merging, of course.

@jonringer Squashed and rebased onto master

commits should be "logical units", and most people interpret that as, "if i were to cherry-pick these commits, what level abstraction would i expect"

For package additions, it's usually one per package