Satish Balay <ba...@mcs.anl.gov> writes: > On Sat, 31 Oct 2020, Jed Brown 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 >> >> 1. Do work in the PETSc repository >> 2. Fork Ed's repository, create branch, update, and push >> 3. Point PETSc CI to the fork >> 4. Submit PETSc MR, review, and merge >> 5. Submit PR to Ed's repo, review, and merge >> 6. Update PETSc CI to once again point at Ed's "main" branch > > we had similar workflow with petsc4py before it was merged into petsc repo.
petsc4py tests didn't run as part of CI, we just fixed issues when they were reported or a developer encountered them. We merged it into the PETSc repository largely because adding it to CI as an external repo would be too taxing. > primary difference: a branch in a fork vs branch in upstream petsc4py > [alternative to switch back and forth with fork vs main repo is always have > the fork be mirrored..]