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

[Satish Balay]

On Sat, 31 Oct 2020, Ed Bueler wrote:

> Maybe I should chime in with what I am thinking.  I'm not thinking dev.
> 
> barry>  I have no problem updating any of Ed's examples if we need to with
> each release, so the burden doesn't fall on him.
> 
> It really isn't a burden to keep the small number of small codes in my repo
> up to date.  I have been doing it for a couple of years now.  The size of
> this "burden" scales with the number of my codes times the rapidity of
> petsc releases; I don't see why this should go out of control.
> 
> On the other hand, keeping my codes up to date _is_ part of authoring the
> book.  While these examples should be kept working with the latest petsc
> release, which forces certain changes, my goal will also be to keep them
> from drifting away from the text of the book.  That is, their documentation
> is essentially fixed, so their feature/API/idiom drift should be
> minimized.  E.g. I will not add functionality to the codes, even if that is
> easy to do, if it makes understanding the originally-intended functionality
> harder, as long as there is a non-deprecated idiom to keep.  I'll take
> seriously all MRs (and issues) on my repo, but I may well not include the
> latest idiomatic petsc.
> 
> If there is ever a second edition that would be the time to bring
> everything fully up to date, syncing (a subset of) the latest petsc api
> with the examples and the text of the book.
> 
> So I guess my question about including my examples into the petsc CI is to
> ask if that is really what you want?

I guess the question is - what issues does CI address. (and the cost). And what is the alternative (and cost)

One issue is: updating the examples when interfaces change.

This can be done incrementally [as PETSc changes] and this is CI
friendly. Alternative is to make the changes at release time - in a
single go. This might be more time optimal for you [as from the above
- you have specific goals wrt what changes are ok - and what are not -
so best for petsc developers not to do these changes. so perhaps CI is
not suitable for this issue]

The other issue is: if there is a change in petsc that fundamentally
breaks the examples. And if so - know about this change immediately -
before the change is merged - and re-evaluate the change. CI is
suitable for this issue.

But this would require constant monitoring of all PETSc merge requests
[that break the examples].


>  If you find that one of my codes is
> useful as a regression test then perhaps bring it over and let it evolve
> separately?  Or just set up CI to let me know that there is a fail in my
> latest commit (i.e. the one that you cloned during CI), but don't make the
> whole run fail because of it, and also don't expect to merge my fixes into
> your fork?

The current CI is for feature branches - before merge to master [or
release branch - for fixes].  We can mark a test as 'ignore failure'
[so that the MR is not blocked on this failure].

There will be some coordination issues - as CI is on a feature branch
(so that the feature issues can be addressed before merge to
master). However your examples repo is likely to be in sync with
petsc/master branch (i.e after the feature is merged in). And the
complexity here is to locally test fixes for these issues [i.e
maintain a fork] - or not [let the CI have non-blocking failure until
the issue is resolved in your repo]

Also - you would need different branches for the examples repo so that they
are maintained for each of the petsc releases.

Satish

> 
> Ed
> 
> 
> 
> On Sat, Oct 31, 2020 at 2:21 PM Jed Brown <jed at jedbrown.org> wrote:
> 
> > Barry Smith <bsmith at petsc.dev> writes:
> >
> > >> On Oct 31, 2020, at 9:35 AM, Jed Brown <jed at jedbrown.org> 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
> > >>
> > >
> > > 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.
> >
> 
> 
>