MapServer Development Process?

[Sean Gillies]

On Jun 23, 2005, at 10:38 AM, Frank Warmerdam wrote:

> On 6/23/05, Sean Gillies <sgillies at frii.com> wrote:
>> Hi all,
>> =20
>> After listening to van Gulik's presentation, does anybody feel that 
>> the
>> MapServer project might benefit from a harder look at its development
>> process?
>
> Sean,=20
>
> 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 
> potentiall=
> y
> contentious code/functionality changes.=20

More branching and merging in CVS, or just more formal policy about 
working in HEAD?

> ...
>> 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.
>
> I think that this should apply to architectural, API or user changes 
> with
> any significant scope but that folks should still be free to do local 
> tweak=
> s
> to the areas of code they "own" without needing a discussion. For 
> instance,
> if Assefa wants to add support for a new Filter operator, or I add 
> support =
> for
> greyscale+alpha in the raster renderer, those don't have adverse 
> effects
> on users, and don't affect widely used interfaces in the code.  But 
> changes
> with broader effects should be (in my opinion) explained and justified 
> on
> mapserver-dev.  And we might well use the same voting approach as=20
> Apache.  Essentially this would mean that if no one had an issue or 
> wanted
> to get involved the person could assume permission to proceed in a 
> couple
> of days.   Well, they could proceed in the meantime, but not commit.=20

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.

> ...
>> 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?
>
> Well, we do have an architecture, so I think you will need to be more
> specific about what sorts of specifications you would like to see. =20
> Is it that you want things documented better?  Perhaps you want=20
> specified APIs for mapserver?  Currently I think our "architecture"=20
> centers around a common "shapeObj" definition, and a layer rendering
> approach.  =20
>
> We haven't traditionally tried to maintain a stable external API 
> except as=
> =20
> represented in MapScript.  I think we are moving to have the mapscript
> API relfected in concrete C functions rather than having alot of=20
> functionality embedded in the swig wrappers.=20
>
> We also have an architecture for output driver handling, input 
> datasources
> and so forth.  However, the "specification" hasn't been all that clear 
> at=
> =20
> times and we haven't generally made them plugable which I think would
> be desirable.=20
>
> So, I guess my conclusion is, point out what aspects of the 
> architecture
> you want improved. =20
>

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?

As far as improvements of the physical code architecture go, I'd like 
to have a C API, and better modularization. Significant work now can 
require modification of many different files. Mark Cave-Ayland had a 
lot more to say about this in another email. The input plugins will 
definitely take us in the right direction.

> I would add that I am still not keen on a big rewrite, but I am 
> interested =
> in
> continued improvement on a sub-system by sub-system basis.  I like to
> think of my effort with outputFormatObj's as bring clarity and a 
> cleaner
> architecture to supporting multiple output formats (for instance).=20
>

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.

cheers,
Sean