[petsc-dev] [petsc-users] new book introducing PETSc for PDEs

[Satish Balay]

On Sat, 31 Oct 2020, Jed Brown wrote:

> Satish Balay <balay at mcs.anl.gov> writes:
> 
> > On Sat, 31 Oct 2020, Jed Brown wrote:
> >
> >> Barry Smith <bsmith at 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.

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..]
>