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

[Ed Bueler]

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?

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


-- 
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/8e7b50d4/attachment.html>