MapServer Development Process?

[Sean Gillies]

Hi all,

After listening to van Gulik's presentation, does anybody feel that the 
MapServer project might benefit from a harder look at its development 
process?

I like the voting idea, and I think we should adopt it. I also think 
that votes should be weighted by the number of tests that you have 
written and committed to CVS ;) That was a joke. A voting system will 
require better communication. The Apache projects demand that all code 
decisions take place in the open, and we should adopt this as well. 
This means that decisions will not be made between Howard and I on IRC, 
or behind closed doors at DM Solutions. In the open means on the 
mapserver-dev list. We do a fair job of this, but it could be better. 
Writing this in stone and holding each other to it could help to head 
off future problems.

It's also long past time to have some tests for MapServer. I propose 
that we start with the new input plugins: no plugins committed without 
tests. These should be tests that can be run under valgrind, and should 
also be automate-able.

My last point is not so much about process as about direction and 
design. I cracked Frank up after the conference by asking what he 
thought about how successful Apache became following a complete 
re-write. I was only half joking. MapServer, as a prominent user said 
to me, has no architecture. Do we put off creating an architecture 
until it becomes practically impossible to add new useful features? It 
seems to me that GRASS got in trouble this way. Do we really want to 
wait until MapServer is widely perceived as clunky and fragile before 
making a change?

cheers,
Sean

--
Sean Gillies
sgillies at frii dot com
http://zcologia.com