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

[Barry Smith]

> On Oct 31, 2020, at 5:55 PM, Ed Bueler <elbueler at alaska.edu> 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?  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?
> 

  Any fixes you make would get pulled by us into our fork, you would never need to do this. Any fixes we make, due to failures in the CI when we change something in PETSc that breaks something, would only get into your copy through an MR. 

  If we made an idiomatic change in PETSc, we would not make a change to the fork to the new idiom, we would insure that our backward compatibility would allow your code to continue to work; in fact this would be a great way to test to make sure we have done our backward compatibility correctly (currently we have no tests of that).

  So our MR would be just like any MR that came in to you from one of your readers with a correction to something that failed.

  Of course, all this stuff would be the same regardless of whether we use my suggested approach or Jed's subtree approach.

  Barry

> Ed
> 
> 
> 
> On Sat, Oct 31, 2020 at 2:21 PM Jed Brown <jed at jedbrown.org <mailto:jed at jedbrown.org>> wrote:
> Barry Smith <bsmith at petsc.dev <mailto:bsmith at petsc.dev>> writes:
> 
> >> On Oct 31, 2020, at 9:35 AM, Jed Brown <jed at jedbrown.org <mailto:jed at jedbrown.org>> wrote:
> >> 
> >> Barry Smith <bsmith at petsc.dev <mailto: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.
> 
> 
> -- 
> Ed Bueler
> Dept of Mathematics and Statistics
> University of Alaska Fairbanks
> Fairbanks, AK 99775-6660
> 306C Chapman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20201031/43581b2d/attachment.html>