<div class="gmail_quote">On Sat, Jun 4, 2011 at 15:09, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
When dealing with tracking package changes I've found the best way is to track them continuously so each new issue (due to a change) gets fixed immediately rather than waiting until a bunch of stuff is broken before fixing it.</blockquote>
</div><div><br></div><div>My thoughts, not specific to SAMRAI:</div><br><div>When we make an API change in PETSc, we have to update all the PETSc examples. If I know that a certain API change impacts a library that I occasionally interact with, I sometimes go update that library at the same time. For example, I have done this a few times for Libmesh. If the project has a public repository, straightforward build system, and a test suite that is easy to run, this doesn't take a great deal of effort. This is, if the time required to update a call, test it, and submit a patch is actually dominated by editing source code, then it's not such a big deal. Note that for many projects, the time ratio is more like 3 minutes to edit the code and an hour to update source, reconfigure, build, test, and submit.</div>
<div><br></div><div>Obviously we can't promise this for lots of libraries, but it's much more likely to happen if you make it really easy. Having nightly tests obviously helps too.</div>