On Sat, 31 Oct 2020, Jed Brown wrote: > Satish Balay <[email protected]> writes: > > > On Sat, 31 Oct 2020, Jed Brown wrote: > > > >> Barry Smith <[email protected]> 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.
We didn't run petsc4py test suite - but we have a minimal petsc4py test. So if there was a change in petsc (feature branch - in MR) that broke petsc4py - it was found - and fixed [before this MR was merged] And yes - one difference here would be - we would have to both build and run the tests in this repo. Satish > > > 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..] >
