[vtk-developers] Fwd: vtkOFFReader / VTK archive system

[Berk Geveci]

We have been discussing how to make it easier for developers without
write access to the repository to contribute code to VTK. We have
considered a few options, including a VTK Journal but no decisions
yet. I would encourage developers to continue this discussion so that
we have an idea what the community thinks and wants. A few
alternatives we have been considering:

* Setup a VTK Journal. Note: this doesn't mean that we would require
the submission of an article to contribute any code to VTK. We believe
that such a process is too heavy handed and would throttle VTK
development. We have yet to figure out how this would work.

* Setup a  VTK contributions repo that is one layer above core VTK.
This would be tested and supported by the development community.
Kitware would host this repo.

* Setup a VTK-related work repo that is one layer above VTK core and
contributions. This would be as-is and not necessarily maintained by
the development community but by the owners of each project. Kitware
would host the repo or provide links to a collection of repos.

We also talked about modularizing VTK a bit better so that most of the
kits are optional builds (maybe even optional downloads)? For example,
we may have:

* Core VTK
* VTK for image processing
* VTK for scientific analysis
* VTK for informatics
* VTK polygonal rendering
* VTK volume rendering
* VTK for distributed processing
etc etc.

What do you think?

-berk

On Fri, Oct 16, 2009 at 10:37 PM, Sean McBride <sean at rogue-research.com> wrote:
> On 10/16/09 7:58 AM, David Doria said:
>
>>The IJ is nice, but it seems rare (from my limited experience) that someone
>>actual improves and resubmits code. I feel like developers would be much
>>more likely to make a few improvements and then simply type "commit" than to
>>repackage the whole thing for resubmission including updates to the tex
>>paper etc. It also seems a bit silly to make a submission to such a journal
>>with a 100 line source file and an even shorter "article" simply saying
>>"this class can read basic OFF files". If that's the recommended process
>>though, I'll partake.
>
> I'm inclined to agree here.
>
>>Another thing (@David Gobbi) - sending these things to the list (as I did
>>and you recommended) is a good idea, but I frequently hear people
>>complaining about how the list is hard to search, etc. Also, the link to the
>>files will certainly die at some point, at which point it is clearly no
>>longer useful. To use the mailing list for archival, I guess you'd have to
>>copy/paste code into an email, which seems like a bad idea. If not a Review
>>directory, then what about an ftp server or something where at least these
>>things can be archived in a semi-maintained place (at least one that won't
>>accidentally die)?
>
> The bug database seems appropriate here.  You can attach patches and
> even entirely new classes.
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>
>
>
> _______________________________________________
> 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
>
>