<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 3 Apr 2022 at 18:30, Barry Smith <<a href="mailto:bsmith@petsc.dev">bsmith@petsc.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div>  I think it is a great idea to test on publically available supported packages that have public git repositories and a decent testing infrastructure regularly and even feed any information that comes up to the packages team in advance. I can think of PFLOTRAN, FireDrake, and MOOSE as good starting candidates. I think we should help those teams add a switch to their test system to use PETSc main when appropriate, I don't think we should be adding such stuff inside the PETSc test world. Note that Slepc and HPDDM are already in the fold and this already takes place with them.</div></blockquote><div dir="auto"><br></div><div dir="auto">FWIW, we (firedrake) effectively track petsc main updating approximately monthly (sometimes more frequently depending), so we've in fact never been tieing ourselves to a petsc release cycle. We might move to a twice-yearly release cycle in the next year or so, but would just use a point in the sand for petsc, rather than relying on a petsc release in that case. We have testing already in place (or coming soon, I think) to check if we build with latest main and auto-fast-forwarding the branch pointer. </div><div dir="auto"><br></div><div dir="auto">We're mostly inured to C API changes as long as the petsc4py interface doesn't change at the same time.</div><div dir="auto"><br></div><div dir="auto">Lawrence</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" dir="auto"></div></blockquote></div></div>