On a ParaView MR, we started having a discussion which should be discussed here.
ParaView uses VTK as a submodule and usually the developer that update the VTK submodule is responsible for fixing any issue that may arise related to the submodule update.
It means that sometimes, based only on luck, this developer as to fix ParaView so it builds and works correctly with new changes in VTK that have nothing to do with the reason he is currently updating the VTK submodules.
In my opinion, it is completely fine to do that when the changes needed are a few baseline updates or small warning fixes that can be fixed in a matter of minutes.
It is not fine when it requires to spend multiple hours, especially if a deadline is coming or if the developer has no expertise at all in the related code. It is hard to draw the line, though, so here are some ideas to improve that :
Developers working on VTK and software dependent of VTK should be diligent in testing their VTK branch with these dependent software before merging and assume the responsibility of correcting any issue that may arise, even if they do not update VTK themselves. This is in general already done imo, but could be formalized.
API breaking changes or profound non-retro-compatible changes could be announced, a few days before they are merged, with ideally an idea on how to fix issues and build failures in the software that depend on ParaView. These could then be compiled into a porting guide provided with VTK releases.
VTK buildbots could be dedicated to build VTK-dependent software that we develop at Kitware (ParaView, Slicer, CMB, Tomviz…), so VTK only developer could inform ahead of time that someone, on these projects, will need to take care of correcting the build issues.
What are your takes on that ?