<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 31, 2020, at 5:55 PM, Ed Bueler <<a href="mailto:elbueler@alaska.edu" class="">elbueler@alaska.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Maybe I should chime in with what I am thinking. I'm not thinking dev.</div><div class=""><br class=""></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 class=""><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div></div></div></blockquote><div><br class=""></div> 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. </div><div><br class=""></div><div> 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).</div><div><br class=""></div><div> 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.</div><div><br class=""></div><div> Of course, all this stuff would be the same regardless of whether we use my suggested approach or Jed's subtree approach.</div><div><br class=""></div><div> Barry</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Ed</div><div class=""><br class=""></div><div class=""><br class=""></div></div><br class=""><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" class="">jed@jedbrown.org</a>> wrote:<br class=""></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" class="">bsmith@petsc.dev</a>> writes:<br class="">
<br class="">
>> On Oct 31, 2020, at 9:35 AM, Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank" class="">jed@jedbrown.org</a>> wrote:<br class="">
>> <br class="">
>> Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank" class="">bsmith@petsc.dev</a>> writes:<br class="">
>> <br class="">
>>> 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 class="">
>>> 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 class="">
>>> PETSc release.<br class="">
>>> <br class="">
>>> Barry<br class="">
>>> <br class="">
>>> We just make this part of our release process.<br class="">
>> <br class="">
>> If we add it to CI, the workflow is<br class="">
>> <br class="">
><br class="">
> 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 class="">
> This would remove the need to fork constantly I use this model partially for adol-c<br class="">
><br class="">
> Anything wrong with this model?<br class="">
<br class="">
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 class="">
<br class="">
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 class="">
</blockquote></div><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">Ed Bueler<br class="">Dept of Mathematics and Statistics<br class="">University of Alaska Fairbanks<br class="">Fairbanks, AK 99775-6660<br class="">306C Chapman<br class=""></div></div></div></div></div></div></div>
</div></blockquote></div><br class=""></body></html>