Skip to content

Merging Lacuna version #9

Description

@matthijskooijman

Hey @mkuyper! You mentioned you're planning to make this repo the primary repo for BasicMac and would welcome pullrequest. As you've heard, we've done quite a bit of work at https://github.com/LacunaSpace/basicmac which would probably be good to merge with your work.

The work we've done is for a large part Arduino support (but this time while keeping the existing build system intact), improved portability (i.e. 8-bit AVR support), some actual fixes and a bunch of cleanups (in preparation of adding LoRa-E support, which is not yet public). I see that your changes mostly focus on the surrounding machinery (STM32 hal, services, board support), which we've mostly left untouched. That makes me hopeful that merging would be possible without too much conflict resolution.

However, before I invest the time to prepare a pullrequest for this, I'd like to discuss how we should do this exactly.

Some thoughts:

  • We've collected quite a bit (140-ish) commits already (there mostly small and well-commented for easy review, though). It might make sense to submit these in multiple pullrequests separately (grouped by theme), but I expect that will make this a lot more work on our side. Also, reordering commits is probably going to be painful (even if there's no logical dependency, there's often textual dependencies between commits that make this tricky). So it would be my preference to do one bulk merge now, and then for future changes take a more gradual approach.
  • I'm wondering if we should be doing an actual merge (so creating a merge commit and solving conflicts in there), or do a rebase of our changes on top of yours (fixing any conflicts in the original commits). The latter might be easier and produce a cleaner history, but the former ensures that the result is actually a descendant of our current, published, master branch, which prevents issues for people already pulling from our repo.
  • I just quickly tried a merge, with gives a dozen or so conflicts, but nothing that looks hard to fix.
  • If we're doing an actual merge, that means you'll get all of our commits verbatim. If there's anything in there that you wouldn't want to merge, we can't edit the original commits, but we'll have to revert or modify this in new additional commits (which is fine, I think).

So:

  • Would you think a single-merge-with-conflicts-fixed is a reasonable approach?
  • If you look through our the commit log, do you see any changes that you would object to at first glance?
  • If you're happy with this approach, I'll do the merge and prepare a PR, we can continue more in-depth discussion in there.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions