<div dir="ltr"><div>Maybe I should chime in with what I am thinking. I'm not thinking dev.</div><div><br></div>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.<br><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Ed</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 31, 2020 at 2:21 PM Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank">bsmith@petsc.dev</a>> writes:<br>
<br>
>> On Oct 31, 2020, at 9:35 AM, Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br>
>> <br>
>> Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank">bsmith@petsc.dev</a>> writes:<br>
>> <br>
>>> 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 <br>
>>> 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 <br>
>>> PETSc release.<br>
>>> <br>
>>> Barry<br>
>>> <br>
>>> We just make this part of our release process.<br>
>> <br>
>> If we add it to CI, the workflow is<br>
>> <br>
><br>
> 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. <br>
> This would remove the need to fork constantly I use this model partially for adol-c<br>
><br>
> Anything wrong with this model?<br>
<br>
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).<br>
<br>
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.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Ed Bueler<br>Dept of Mathematics and Statistics<br>University of Alaska Fairbanks<br>Fairbanks, AK 99775-6660<br>306C Chapman<br></div></div></div></div></div></div></div>