Barry Smith <bsm...@petsc.dev> writes: >> On Oct 31, 2020, at 9:35 AM, Jed Brown <j...@jedbrown.org> wrote: >> >> Barry Smith <bsm...@petsc.dev> writes: >> >>> I have no problem updating any of Ed's examples if we need to with each >>> release, so the burdern doesn't fall on him. We simply make a fork of his >>> repository with a new branch and update that and make a MR to Ed for each >>> release and he can have a new branch or tag of his examples for each new >>> PETSc release. >>> >>> Barry >>> >>> We just make this part of our release process. >> >> If we add it to CI, the workflow is >> > > I would keep the fork always petsc/pkg-eds-repo and have PETSc master > always point to the fork. At releases we would have release point directly to > eds. > This would remove the need to fork constantly I use this model partially for > adol-c > > Anything wrong with this model?
This takes Ed out of the loop, but doesn't avoid the CI circus that I outlined. It's more reproducible to always pin to a commit hash in the repository, in which case there may be no need to circle back and update PETSc after merging in Ed's repo (or our fork). An alternative would be to subtree the examples into PETSc and export upon release. Ed could be the CODEOWNER so he can weigh in on proposed changes or more idiomatic interfaces that may become available. His repo would always work with the latest release.
