[vtk-developers] Contrib level developers contribution process

Berk Geveci berk.geveci at kitware.com
Sun Oct 18 13:16:20 EDT 2009


I think that this is a good idea. One caveat: the developer that
adopts the patch is likely to put it in his/her queue and get to it
when he has some free time. Most VTK developers are very busy and
applying a patch to a class that one is not directly interested in
will have lower priority than anything else. We should make it easy
for developers to manage this queue. Maybe we can do this in the bug
tracker? The bug entry that contains the patch would be assigned to
the owner. Maybe we would also create a new category called something
like "Patch queue"?

As for voting, we will create a uservoice account for VTK soon. I
don't think that there is any reason to maintain multiple systems for
this. Unless uservoice is missing a feature. Is that the case?

-berk

On Sun, Oct 18, 2009 at 9:51 AM, David Doria <daviddoria+vtk at gmail.com> wrote:
> I have some thoughts on another part of the process to consider as
> continue to think about what to change in the contrib process.
>
> I will use a recent example of a small modification to vtkPLYReader
> that I've been involved with as a "case study". I made a small (< 20
> line) change to this class and sent it to the list. Sean showed some
> interest (thanks!), but didn't necessarily indicate that he would be
> willing to take any further action. Without write access to core,
> unless I have some "guarantee" that it will be actually used/included,
> I am really not motivated to:
>
> - modify the ply reader test
> - make a second patch with the new data file along with the changes to
> the Testing/CMakeLists.txt and the actual test file
> - run another experimental dashboard build
>
> I'd recommend an "adopt a patch" type of system where the higher level
> developers can look at some initial work and "guarantee" that "once
> this is done, I will look through it and add it to VTK". This would
> indicate that it is indeed worth working on and there will be some
> closure at the end of the work. There is then no potential for putting
> significant effort into something and then watching it just sit in
> limbo indefinitely. The devel mailing list kind of serves that
> purpose, but it is a bit too informal to make a "guarantee" to the
> contrib level developers that they are working on something worth
> while. If on the mailing list a core level devel says "Let me know
> when it's ready and I'll take a look and commit it", my motivation
> level would go from 2/10 to 10/10 to complete the project. This type
> of thing would get pretty hard to track via email though, hence the
> "adopt a patch system" idea. I think Mantis has this functionality but
> from what I can tell it is not currently used like that. If I put a
> patch on Mantis as a feature request, if one of the core devels
> "assigns" it to themselves that would accomplish this "adopting" that
> indicates they will pursue further after the necessary changes are
> made.
>
> Thoughts? Should we set up some kind of list of options and have a
> community vote about which things make sense to do? I know Paraview
> uses UsersVoice for a voting type system, but surely there are some
> more light weight options?
>
> Thanks,
>
> David
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>



More information about the vtk-developers mailing list