[mapguide-internals] rfc60 ready for review

[Tom Fukushima]

UV,

This has been discussed before.  If you are going to keep bringing this up, I think that you will only alienate yourself more with the core developers.



-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
Sent: December-11-09 9:48 AM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] rfc60 ready for review

Hi Tom,

... stuff deleted...

    In this context a comment to the process:
    I still believe it to be wrong process for an open source project to 
have blocked this useful, transparent and working feature for 2.1 based 
on incompleteness of support of new stylization which
        a) nobody needed at that time which means no complex test cases 
to support development did exist
        b) might not even be so important as area styles are the only 
obvious visible features for color quantization errors
            (lets wait for a big map which is telling us otherwise)
        c) is not particular well documented/specified which in 
combination with missing complex test cases significantly increased the 
coding effort  (color quantization occurs on a complexity level which is 
very difficult to reach with unit level test cases)
        d) has no funding and little motivation to support it because we 
never needed it ourselves.

    Therefore adapting the RFC60 as it was and later create tickets for 
it after somebody exposed something missing with his maps (this way 
creating useful test cases) would be a much more appropriate and 
productive process to deal with such a feature which has been partially 
funded by a client as an external contribution in an open source 
project. Keywords: completeness, funding, motivation &  test cases
    I very much suggest to review your external contribution process 
again. At that time it was discouraging as the additional time spent 
dealing with extending the feature has artificially increased the effort 
to a multiple of the time solving our clients probem.
    Normally coding stops when the client problem is solved and nobody 
else pays for it.
    Dealing with external contributions like this might discourage 
people from contributing their patches to the shared code base, contrary 
to the open source idea. In this case we all were lucky because I had 
some spare time to invest.

...remarks to other points deleted...