Merge in upstream, and understand what upstream we should refer to

[nabadger]

The diff between mintel/alphachai repos is minimal, but the diff between mintel/cloudposse repos is quite large :)

I would prefer the following:

• Fork from cloudposse, since that's going to be getting regular changes
• Maintain build-harness in such a way that bringing in upstream changes has minimal (or no) conflicts. If we're always having to deal with conflicts, then no one is going to want to maintain this :)

@alphachai (hope this still works!). We're starting a few new projects soon which will want shared Mkefiles, so hoping to put work into build-harness here. We want to figure out ownership first (probably SRE+some devs?).

Keen to get your thoughts on this though - there's no impact if we re-fork against cloudposse right? If end up creating useful PR's into build-harness (even the mintel repo), then you could still pull those in.

Also, was there any advantage in removing un-used modules such as #59 - I feel that removing stuff may lead to conflicts when bringing in upstream changes.

[xiang-zhu]

I brought up this before, I think since the time we did the initial fork, build-harness add the ability for easier extending https://github.com/cloudposse/build-harness#extending-build-harness-with-targets-from-another-repo probably worth look into

[nabadger]

This looks perfect, something to look into 👍

[charlieparkes]

This repo should definitely be re-created to fork from the cloudposse repo directly. It was high on my to-do list but never quite made it to the top.

As for refactoring to use their method of extending, you're going to create a lot more work for yourself.

1. There are decisions they made in their version of many targets which we over-wrote to match our (experienced) team's opinions.
2. There are changes to core parts of the build-harness in our fork which can not be replaced via their "extension" method. One example, the install script, is critical to how we use this project. (I have an MR open with them which, after a few months, has had some activity but still no merge.)

There were (and still are) good reasons for why we hard-forked. We don't actually use any of their targets. The purpose was attribution only on the 2-3 core files. I started a branch to merge upstream a few months back, mainly to pull in their testing. I see that as the only strong motivation to do so, even now.

That said, I no longer have a stake in this debate. Happy to help walk through changes to the core files to point out where they diverged and why!

[charlieparkes]

I think it's important to remember that their build-harness exists to enable their CI-CD process when deploying pre-fab clusters and services for their clients. Our environments and practices do not mirror theirs, thus our build-harness does not mirror theirs.