[vtk-developers] development roadmap?

[Michael Halle]

Thanks for the comments and being receptive, Will!

Let me just clarify one point:

> I'm concerned about freezing the CVS repository. Would might happen is that 
> instead of a torrent of changes, you'd have a series of floods each time 
> the gates were opened. These impulse functions create a lot of dynamics... 
> Maybe we could do short freezes around the releases....make use of code 
> branches more.

What I meant was not anything like a complete freeze, but a freeze on
some category of major changes.  For instance, "starting on day XXX,
no change that would impact the correctness of formatting of every
now-current class will happen before XXXX + 2 months, and any changes
to be made will be announced at least 1 month ahead of time."  There
aren't that many of these changes, but a couple have happened lately
(New() changing, and the use of Superclass in the PrintSelf method).
In general, these kinds of changes are not ones of essential
functionality, but rather improvements for style or convenience.  They
usually require significant thought, and they usually can wait a
little while.  These changes are also great for convenience in the
long run, but very inconvenient for outsiders in the short run.  

A freeze in this case might be workable because it doesn't slow down
innovation too much.  It's just slowing the time constant down a
little.  It also forces planning of these big changes, and might
ultimately make them better in the long run.

It would be an interesting extreme programming/team programming
research concept to come up with a metric for code change cost, and
factor it in to the checking in process.

Thanks again.

							--Mike