This repository is an organizational fork of archivematica and we want it to serve two purposes:
- We want full control over the version of archivematica that we are deploying to our various environments:
- We want to be able to make bug fixes / augmentations that get incorporated into our deployments even if they have not been released officially by upstream.
- We want any IaC to point to repositories that we have direct control over.
- We want to be able to make contributions upstream:
- As we make fixes we want our team to be able to create branches that ultimately get turned into upstream PRs.
For (1) we are going to be making improvements to whatever stable branch from upstream is associated with the version we are deploying. This is actually our primary target for our own fixes, since the primary goal is to make changes / patches that will improve the experience for our users.
For (2) we are going to be making improvements to whatever the default branch of upstream is (their current qa branch).
I want to propose that we have the following branch structure:
main is upstream stable.next is upstream default (qa). <-- optional / this would be a convenience branch allowing our devs to write git checkout -b 123-foo-bar next rather than having to look up what the current upstream branch name is.
When there are new stable releases upstream we would update main to sync against the new upstream stable branch.
When there are new version of qa we want to update our next to sync against the new upstream branch.
It's not clear to me if GitHub provides first-class support for having our fork's default branch point to a non-default branch of upstream. It's possible we'll want to treat that synchronization as a manual (or script augmented) step which only happens when we are adopting new archivematica releases.
This repository is an organizational fork of archivematica and we want it to serve two purposes:
For (1) we are going to be making improvements to whatever stable branch from upstream is associated with the version we are deploying. This is actually our primary target for our own fixes, since the primary goal is to make changes / patches that will improve the experience for our users.
For (2) we are going to be making improvements to whatever the
defaultbranch of upstream is (their current qa branch).I want to propose that we have the following branch structure:
mainis upstream stable.nextis upstream default (qa). <-- optional / this would be a convenience branch allowing our devs to writegit checkout -b 123-foo-bar nextrather than having to look up what the current upstream branch name is.When there are new stable releases upstream we would update main to sync against the new upstream stable branch.
When there are new version of qa we want to update our
nextto sync against the new upstream branch.It's not clear to me if GitHub provides first-class support for having our fork's default branch point to a non-default branch of upstream. It's possible we'll want to treat that synchronization as a manual (or script augmented) step which only happens when we are adopting new archivematica releases.