On Sat, 31 Oct 2020, Ed Bueler wrote:
> 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? I guess the question is - what issues does CI address. (and the cost). And what is the alternative (and cost) One issue is: updating the examples when interfaces change. This can be done incrementally [as PETSc changes] and this is CI friendly. Alternative is to make the changes at release time - in a single go. This might be more time optimal for you [as from the above - you have specific goals wrt what changes are ok - and what are not - so best for petsc developers not to do these changes. so perhaps CI is not suitable for this issue] The other issue is: if there is a change in petsc that fundamentally breaks the examples. And if so - know about this change immediately - before the change is merged - and re-evaluate the change. CI is suitable for this issue. But this would require constant monitoring of all PETSc merge requests [that break the examples]. > 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? The current CI is for feature branches - before merge to master [or release branch - for fixes]. We can mark a test as 'ignore failure' [so that the MR is not blocked on this failure]. There will be some coordination issues - as CI is on a feature branch (so that the feature issues can be addressed before merge to master). However your examples repo is likely to be in sync with petsc/master branch (i.e after the feature is merged in). And the complexity here is to locally test fixes for these issues [i.e maintain a fork] - or not [let the CI have non-blocking failure until the issue is resolved in your repo] Also - you would need different branches for the examples repo so that they are maintained for each of the petsc releases. Satish > > Ed > > > > On Sat, Oct 31, 2020 at 2: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. > > > > >
