Barry Smith <[email protected]> writes: >> On Oct 31, 2020, at 5:21 PM, Jed Brown <[email protected]> wrote: >> >> Barry Smith <[email protected]> writes: >> >>>> On Oct 31, 2020, at 9:35 AM, Jed Brown <[email protected]> wrote: >>>> >>>> Barry Smith <[email protected]> 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. > > What do you mean by release (six month release or all the time with master?) > > 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 > > https://www.atlassian.com/git/tutorials/git-subtree > > Drawbacks (but in our opinion they're largely acceptable): > > You must learn about a new merge strategy (i.e.git subtree). > Contributing code back upstream for the sub-projects is slightly more > complicated. > The responsibility of not mixing super and sub-project code in commits lies > with you. > 1 and 3 seem a bit concerning, I will certainly make this mistake constantly > without an automatic system to prevent it. > > ---- > This is not a good sign, git subtree exists, but > $ git help subtree > No manual entry for git-subtree
You're just using an old Git, for which you need to enable it explicitly. > ----- > > Anyways back to my concern. > > 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 > 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. > My approach only requires branching, push, and pulling on the fork and > updating EdsRepo.py which is things all the developers know about and > do regularly since we update other external packages. Circular dependencies (PETSc CI depends on Ed's p4pdes depends on PETSc) are significantly more labor-intensive and it would need to be done on each change, versus once per release cycle.
