MapServer Development Process?

[Frank Warmerdam]

On 6/24/05, Sean Gillies <sgillies at frii.com> wrote:
> Frank Warmerdam wrote:
> > The talk has made me think about code traceability, and for some time
> > I have felt we needed a slightly more formal way of dealing with
> > potentially contentious code/functionality changes.
> 
> More branching and merging in CVS, or just more formal policy about
> working in HEAD?

Sean,

Ack!  No, not more fancy CVS stuff.  Just to keep clearer track of
where contributions are coming from, and possible requesting an 
explicit release of copyright when folks contribute changes.   Possibly
as far as a signed document from contributors. 

In GDAL my only step was to add a COMMIITERS keeping track of
the real world identify of contributors with commit priveledges.  So I
can trace userids back to real people.  That gives me a greater 
degree of tracability.   But an explicit release ought to be requested
for substantial code contributions via bugzilla as well.  

> I think we should vote on just about everything, respect each others'
> experience and special needs, and let this kind of system work out for
> itself how significant a particular effort is. I don't think anybody
> would veto your examples, and we also wouldn't have an artificial break
> between what gets voted on and what doesn't.

Well, there needs to be some dividing line.  I don't plan on soliciting
a vote on minor changes.  ie. adding a debug statement, fixing a small
bug, etc.  

In the Linux world, Linus appoints lieutenants responsible for subareas
of the kernel.  Within their realms they general get to make the decisions,
but for external interface changes, or changes that would affect other
parts of the kernel more general agreement must be reached.   I would
like to see this approach applied in MapServer, at least to some extent, 
to avoid to much noise on the list.  And to avoid 2-day waits for small
changes. 

So, one contentious technical decision we have is whether we ought
to vote just on major things, or even on small ones.   To bad we don't
have a process to decide.  :-)

> While there is a logical architecture, it is not described or
> illustrated in any one place. It can be inferred from the code, but
> otherwise it exists only in our minds and in bits and pieces across
> email threads and bugzilla entries. I'd like to be a part of correcting
> this. If we really do have an architecture, it ought to be pretty easy
> to spell it out, yes?

Well, I don't necessarily agree that it should be easy to spell out.
I would say that much of the architecture is essentially spelled out
in the Map File Reference.  Nevertheless, I am agreeable that an
architecture document would be useful.  One of the things that I 
found to be important when developing GDAL and OGR was to 
define a "data model", in some sense an architecture.  It is helpful
for people to understand GDAL and OGR better, and it makes it
easier for me to decide on where things fit as time goes on. 

> As far as improvements of the physical code architecture go, I'd like
> to have a C API, and better modularization. 

I would agree.  I would like to see a more fixed C API, and better
modularization of code for operating on maps, layers, shapes, etc. 

> Yeah, that was good work that I appreciate daily. I'm hoping that we
> can commit to making such improvements when we can before MapServer
> gets any more complex that it already is.

Well, realiistically I doubt that MapServer will stand still while we 
re-engineer it.   And I would like to think that most complexity is still
being added in a modular way (ie. SVG output support) as opposed
to the occasional messy exceptions (like rotated map support). 
 
Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent