MapServer Development Process?

[Daniel Morissette]

Guys,

I won't reply in details to the whole thread, but here are some comments 
about some of the issues that were raised:

- I like the voting idea too. Actually Frank's proposal for a steering 
committee (MS-RFC-1) sounds like a great start to me.

- I agree that we need as much open communication as possible, and I 
think we've done lots of progress on that front in the last couple of 
years. Let's continue in that direction.

- About code traceability, I think filing bugs for *all* changes, 
including small fixes, and including refs to the bug number in the CVS 
change comment is a good step in that direction. Perhaps the next step 
would be to require anyone with CVS commit rights to sign some kind of 
contributor agreement similar to what Apache has (we'd have to see what 
they have).

- I agree that some portions of the code could use better comments or 
could be better organized. Having a common coding style would help too.

- I am not in favor of a complete rewrite of the software, I am more in 
favor of re-engineering of smaller modules one at a time like we've done 
for the input and output drivers for instance.

- With respect to lack of architecture, my opinion is that MapServer 
definitely has an architecture otherwise it would not work as well as it 
does and we would not be able to talk about modifying it the way we do. 
Perhaps it's not as clearly documented as some people would like it to 
be, but that's a different issue that we could work on.

- As I said many times before, I am all in favor of contributing to a 
good test suite... some day I'll stop just saying it and will find the 
time to start contributing seriously.

I think that's it... great discussion BTW.

Daniel



Frank Warmerdam wrote:
> 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,


-- 
------------------------------------------------------------
  Daniel Morissette               dmorissette at dmsolutions.ca
  DM Solutions Group              http://www.dmsolutions.ca/
------------------------------------------------------------