<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:21 PM, Jed Brown <<a href="mailto:jed@jedbrown.org" class="">jed@jedbrown.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Barry Smith <<a href="mailto:bsmith@petsc.dev" class="">bsmith@petsc.dev</a>> writes:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Oct 31, 2020, at 9:35 AM, Jed Brown <<a href="mailto:jed@jedbrown.org" class="">jed@jedbrown.org</a>> wrote:<br class=""><br class="">Barry Smith <<a href="mailto:bsmith@petsc.dev" class="">bsmith@petsc.dev</a>> writes:<br class=""><br class=""><blockquote type="cite" 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=""></blockquote><br class="">If we add it to CI, the workflow is<br class=""><br class=""></blockquote><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=""></blockquote><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=""></div></div></blockquote><div><br class=""></div> What do you mean by release (six month release or all the time with master?)<br class=""><br class=""></div><div> I have no problem with alternative approaches but they must truly eliminate part of the extra work required by my approach on everyone's part not increase the work. I did find some possible issues with subtree which may or may not apply </div><div><br class=""></div><div><a href="https://www.atlassian.com/git/tutorials/git-subtree" class="">https://www.atlassian.com/git/tutorials/git-subtree</a></div><div><br class=""></div><p style="box-sizing: border-box; margin: 0px 0px 29px; line-height: 1.55556; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; caret-color: rgb(77, 77, 77); color: rgb(77, 77, 77);" class="">Drawbacks (but in our opinion they're largely acceptable):</p><ul style="box-sizing: border-box; margin: 0px 0px 30px; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; caret-color: rgb(77, 77, 77); color: rgb(77, 77, 77);" class=""><li style="box-sizing: border-box; margin-bottom: 20px;" class="">You must learn about a new merge strategy (i.e.<code style="box-sizing: border-box; font-family: Nimbus, Monaco, monospace; font-size: 17px; display: inline-block; padding: 0px 2px 0px 5px; color: rgb(51, 51, 51); letter-spacing: -1px; text-indent: -3px; text-rendering: optimizeLegibility; word-spacing: -1px; white-space: nowrap;" class="">git subtree</code>).</li><li style="box-sizing: border-box; margin-bottom: 20px;" class="">Contributing code back upstream for the sub-projects is slightly more complicated.</li><li style="box-sizing: border-box; margin-bottom: 20px;" class="">The responsibility of not mixing super and sub-project code in commits lies with you.</li></ul><div class="">1 and 3 seem a bit concerning, I will certainly make this mistake constantly without an automatic system to prevent it.</div><div class=""><br class=""></div><div class="">----</div><div class="">This is not a good sign, git subtree exists, but</div><div class=""><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">$ git help subtree</span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">No manual entry for git-subtree</span></div></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">-----</span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">Anyways back to my concern.</span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">git subtree does require use of new commands every time you mess with it (say every three months) that we do not know and since each of </span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">us will do this infrequently it is likely we will not remember them (I won't) while my approach does not require remembering new commands. </span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">My approach only requires branching, push, and pulling on the fork and updating EdsRepo.py which is things all the developers know about and </span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class="">do regularly since we update other external packages.</div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">If we all needed to use git subtree often then the extra burden of learning it and remembering it would just happen, but since we are </span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">likely to use it infrequently it is not clear to me that the extra burden of everyone learning subtree is truly simpler than my approach for everyone but you. </span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class="">Also making Ed a code owner seems to give him an extra unneeded burden by sending mail for every trivial fix, that he would not face if we just submitted MR to him when anything dramatically changes and at release time.</div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class="">----</div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class="">I would just put the fork of Ed's repository in a couple of pipeline tests with --download-edsrepo then people don't need to monkey with it themselves unless there is a failure and if there is a failure they proceed just like any other external package, add --download-edsrepository locally, fix in the downloaded repo, push, change the commit in edsrepo.py and push. </div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">In conclusion, if you can demonstrate that git subtree is truly simpler for all of us including Ed, then definitely we should use it. But I have my concerns that it actually adds a good amount of unneeded new complexity. </span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> Barry</span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; font-stretch: normal; font-size: 16px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div> </div><br class=""></body></html>