[vtkusers] Contibuting to VTK

[KenLists]

Hello Neil,

I'll take a stab at answering your questions.

> 1) If we contribute new code that is accepted into VTK,
>   how is that code maintained (i.e. defect fixes, public interface
>   and implementation changes)  in the future.  Is it
>   Kitware's responsibility or are the initial developers
>   expected (or allowed to if they want to)  to provide support
>   as well.

Certainly the initial developer is allowed to fix defects. With respect
to API changes that really depends on how widely used the contributed
class is. Typically when a new class is added the API changes as more
people start using it and the developer receives suggestions. But...
once a class is widely used then making API changes that are not
backwards compatible becomes painful. Think of it as some sort of
nonlinear function over time and use. The more people that are using the
class the less you want to mess with the public API. 

As far as who's responsibility is it to maintain the code? The answer is
that it is really no one's "official" responsibility. Generally, since
Kitware sells support for VTK and makes releases we will maintain
contributed code once it has made it into a release of VTK. But that
level of maintenance depends to some extent on our support customers
caring about the contributed code. If someone contributes a class to VTK
for interfacing with their Delorian time traveling car then it will not
get much maintenance (beyond compiling and warnings) because our support
customers are not using the class (I'm assuming that they do not have
such cars). 

On the positive side, many of the contributed classes are supported very
well by their original developers. I know David and Prabhu have done
some great Python work for VTK and they (and other Python folk)
generally do a great job maintaining the code and supporting it. And
finally, as a community, most VTK developers will maintain each others
code as needed or when they find a problem.  

> 2) How are "improvements" to existing code that we might make handled.
>    For example,  there is a class (deLaunay3D) that we would like to
>    extend in terms of offering a wider ranging public interface.
> 
>    Do we seek permission from Kitware to do this (we won't bother if
>    it's  not allowed) and then submit the changes ?

When improving an existing class generally common sense is the rule. If
the change is fairly minor (e.g. adding a get method to return the final
error metric for the deLaunay3D) then there isn't a need to discuss the
change. As the improvements become more significant, or involve adding
significantly more code then it is usually worth raising the issue to
the vtk-developers mailing list for discussion. If it is a very
significant change then you should email vtk-developers with a subject
line that includes ARB so that the ARB folks will know to read the
email. 

Developers who do a lot of editing of VTK code generally become VTK
developers and get write access to CVS so that they can commit and
maintain the code themselves. If it is occasional submissions then the
code can be emailed to an existing VTK developer.


> 3) On what time scale do we expect submitted code to find its way
>    into the daily VTK system in the categories
> 
>    . simple bug fix
>    . extended functionality (as in the example above)
>    . new classes
> 
>   assuming the VTK coding and functionality guidelines have been
followed.
>   I.e. is there a formal and well-defined process for this ?

If you have write access then it happens when you check it in. Otherwise
it really depends on who you are submitting the code through (since they
will get beaten up if the code doesn't compile/breaks existing tests
etc). There isn't a formal entry point for emailed code submissions.
Usually someone who is familiar with the code will take charge (for
example anything to do with deLaunay3D I would direct to Will Schroeder)
We do have a bit of a problem with bug reports and bug fixes not making
it into the main VTK tree because the email doesn't get properly
handled. We tried a bug tracker once but it became a bit much to manage
.... 

Thanks
Ken