[mapguide-internals] RE: Project Sponsorship

Wed Nov 26 12:55:55 EST 2008

Kenneth,

I agree with you completely that developer documentation is not readily available as it should be.
This is being worked on.

If you are looking for the HTTP API documentation - that hasn't been written yet and is something we would like to do.

The goal here is to completely document the API.

I have updated the architecture documentation to include the operation processing information you have requested. http://trac.osgeo.org/mapguide/wiki/MapGuideArchitecture#OperationProcessing

Note: There is still lots more to add to the architecture document that I am still working on.

Thanks,
Bruce

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Kenneth Skovhede, GEOGRAF A/S
Sent: Tuesday, November 25, 2008 3:35 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] RE: Project Sponsorship

The issue I was trying to fix was:
http://trac.osgeo.org/mapguide/ticket/305

The issue number reveals that it was some time ago I asked for extra info.
What I managed to do was to build everything in debug mode, and start it up.
When the request arrives, I have a vague guess at what function will be
activated,
so I set a breakpoint there. After a little stepping, the request hits
the ACE
dispatcher code. Since I have no idea where the request is handled, I
cannot set
a breakpoint there. I am also unable to determine what request are in
queue, and why.

What I asked for way back then (and I still need to continue tracing the
bug) is
documentation that explains what types of packages are avalible, where
they originate
from and how a typical flow of a request goes. From my point of view,
that is
Core Documentation, which is something I can only see Autodesk producing.

This may not repesent the needs of others, but it is what I need to
trace that
particular issue. And I must say, I am very reluctant to look at the
MapGuide
code base again until I see such documentation.

I also tried to implement this RFC:
http://trac.osgeo.org/mapguide/wiki/MapGuideRfc21

The breaking point here was the lack of documentation for mapping WebAPI
calls
to the server methods (too long ago to remember clearly:)).

I also tried to fix this issue:
http://trac.osgeo.org/mapguide/ticket/272

The problem here was missing documentation for the GwsQuery system,
which I requested on the mailing lists. (again, very long time ago).

Regards, Kenneth Skovhede, GEOGRAF A/S

Tom Fukushima skrev:
> Hi,
>
> It's nice to hear what you all are thinking.
>
> Seeing this, I think that to get other developers involved we need to:
> * Get more documentation about the architecture out there.  Bruce has started something here, but what other things are we looking for.
> * Help developers when they ask questions.  I monitor for questions on this mailing list, but it looks like I have missed some of Kenneth's questions. If anyone asks development questions on MapGuide-internals they should be answered; feel free to send me a personal email if you don't see any responses.
> * Fix the build process.  Actually, on Windows, I find that the build is quite painless.  It is getting the web tier up and running that does me in.  I don't know what we can do here.  On Linux, it seems that the build is painful, but getting everything up and running is easy; I think that Helio is working on this.
> * Is there anything else?
>
> Also, working to fix a particular defect is a good way for a developer to get started.
>
> The above said, I don't want to spend a lot of time getting a developer up to speed who will only be working on the project for a short time (e.g., to fix a single defect). So with this in mind, the documentation is probably most important in my mind;  I guess we need to figure out what is needed here.
>
> BTW, we spent a lot of time looking into the GDAL provider problem recently and did not find any stability problems with GeoTIFF. We were going to update the ticket with the information, but it looks like that hasn't been done yet. There is a memory leak and that will cause a crash after a while, but we don't see any threading problems.  So with MGOS 2.0.2 and GeoTIFF (use GDAL to create these) things are stable.
>
> Regards,
> Tom
>
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Kenneth Skovhede, GEOGRAF A/S
> Sent: Monday, November 24, 2008 1:15 AM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] RE: Project Sponsorship
>
> I find that you and Zac are right to the point.
>
> I have tried many times over to debug something in MapGuide, but there
> is simply
> no core documentation avalible. The internal division in request and
> response packets
> make sense from a performance perspective, but since there is no
> documentation
> on what the request/response flow is, it is very difficult to trace a
> package.
>
> I have requested such documentation before, but have not seen it yet.
>
> A mentor would be nice, but for starters, a "core developer guide" would be
> more helpfull (to me at least).
>
> Regards, Kenneth Skovhede, GEOGRAF A/S
>
>
>
> Andy Morsell skrev:
>
>> I completely agree that the majority of sponsorship interest from community
>> members will be around targeted bug fixes and feature development.  I also
>> agree that right now we're very limited by a small group of core developers
>> as being our only resource to assist in getting the bugs fixed and the
>> features developed.  Most MapGuide users simply do not have the skills to do
>> core development work so are reliant on the existing developer group.  The
>> existing developers are clearly starting to get frustrated that not many
>> other developers are jumping in, but it seems that there just aren't that
>> many folks with the right skills to help out in the ways that are needed.
>>
>> I have actually offered to contribute money more than once (case in point,
>> $500 to Frank's plea for help) to specific items and nobody ever took me
>> (and others) up on these offers, regardless of whether there was an official
>> sponsorship model in place.  Based on this, I'm not overly optimistic that
>> it will have much effect unless the individual tasks are able to be treated
>> like profitable projects by the developers.  Much the same way it makes
>> sense for DM Solutions and other consultants to get paid by clients to do
>> development and contribute it back to the project.  Only in this case, it
>> wouldn't necessarily be for a specific client, but rather for the project
>> itself.
>>
>> The bottom line: it hasn't seemed to matter how much money we've been
>> willing to throw at the project if we don't have the resources to do the
>> work...... Perhaps the sponsorship program will draw some worthy developers
>> out of the woodwork, so I think it's worth continuing to explore it.
>>
>>
>> Andy Morsell, P.E.
>> Spatial Integrators, Inc.
>> www.SpatialGIS.com
>>
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org
>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
>> Sent: Sunday, November 23, 2008 6:00 PM
>> To: MapGuide Internals Mail List
>> Subject: Re: [mapguide-internals] RE: Project Sponsorship
>>
>> Generally speaking, aside from general sponsorship for the general
>> stuff (build infrastructure), one of the main things
>> where i see organisations being interested in sponsorship is very
>> targeted bug/feature development.
>>
>> To take the example of a company or individual deciding for example
>> they really need the GDAL FDO provider fixed
>> and deciding they want to commit their own resources to fixing this,
>> they really need mentoring
>>
>> The classic example was Frank Warmerdam putting his hand up to resolve
>> this bug and asking for assistance from
>> a mapguide developer. His requests went unanswered (AFAIKT) and this
>> issue remains unresolved.
>>
>> A similiar example is the CMAKE build process which Helio was (is) working
>> on
>>
>> Currently, nearly all the development on Mapguide is being done via
>> Autodesk employees and as a result Autodesk
>> have a strong vested interest in the project, but this also forms a
>> barrier for external developers to get involved in the project.
>>
>> Jason's idea of a portal manager, is being performed by the community
>> at them moment and that is working reasonably well.
>>
>> What is really needed is a something like a 'development mentor /
>> champion' available within the Autodesk team who can
>> assist / guide external developers and capture this information along
>> the way, either via wiki articles or via the mailing list.
>>
>> Making the build process simpler is critical, when a developer can
>> simply check the code out and build it and start hacking,
>> they are much more likely to actually start developing and
>> contributing code back to the project.
>>
>> The current complexity of the build process means that a lot of people
>> start, getting stuck in build issues and loose interest.
>>
>> http://how2map.blogspot.com/2008/11/mapguide-shaping-up.html
>>
>> z
>>
>>
>>
>> On Mon, Nov 24, 2008 at 11:53 AM, Jason Birch <Jason.Birch at nanaimo.ca>
>> wrote:
>>
>>
>>> I'd prefer to work out the details before going to vote; two votes  will
>>>
>>>
>> just slow down the process.
>>
>>
>>> Looking at the GDAL and OpenLayers examples, I believe that there are
>>>
>>>
>> quite a few differences in what we could feasibly apply the funds toward at
>> this point, primarily because of our developer/user mix.  However, some of
>> the important tenets (PSC directs the use of funds, sponsors get full
>> reporting on use of funds and feedback through annual questionairres, etc)
>> feel right to me.  I also think that we should have a mechanism for
>> sponsorship funds to be earmarked for specific PSC-approved projects,
>> assuming that at some point we find developers within the community
>> interested in undertaking this kind of work.
>>
>>
>>> Apart from the necessary infrastructure for continuous builds and
>>>
>>>
>> installer packaging, why do we need sponsorship, goals and specifics?  I've
>> got some thoughts, but I'd like to hear from everyone.
>>
>>
>>> Goals:
>>>  - Increase the level of community participation in the MapGuide
>>>
>>>
>> development process
>>
>>
>>>  - Enhance the quality of the project's communications (announcements,
>>>
>>>
>> tickets, release transparency, etc)
>>
>>
>>>  - Ensure that project is approachable by new users, especially in the
>>>
>>>
>> areas of documentation, code samples, initial install experience, etc.
>>
>>
>>> Potential uses (examples only, actual PSC-approved expenditures may
>>>
>>>
>> differ):
>>
>>
>>>  - Maintain project-specific infrastructure necessary to support a fully
>>>
>>>
>> open development environment -- OSGeo takes care of things like Trac, SVN,
>> and downloads very well for us, but seems to be under-resourced for
>> supporting a continuous build framework, especially for projects such as
>> ours which require strong Windows support.
>>
>>
>>>  - Partial funding for a portal manager, ensuring that tickets are
>>>
>>>
>> followed up, email issues are referred to the Trac system where appropriate,
>> new releases are tagged with best possible information on date, etc.
>>
>>
>>>  - Creation and maintenance of MapGuide installers/packages for a wider
>>>
>>>
>> range of operating systems
>>
>>
>>> I'm sure there is much more, and maybe some of these aren't in sync with
>>>
>>>
>> everyone's thinking.  There is also some thought to be given to what
>> sponsors can expect from this, other than higher quality software and
>> community recognition.
>>
>>
>>> Please let post to the group with your items, etc.  Clearly separate goals
>>>
>>>
>> from potential uses, and ensure that the uses can be tied back to specific
>> goals.  Once we get a bit of cohesiveness, this should all go in a wiki for
>> collaborative editing.
>>
>>
>>> For reference:
>>>
>>> http://www.gdal.org/sponsorship.html
>>> http://openlayers.org/sponsorship/
>>>
>>> Jason
>>>
>>> ________________________________
>>>
>>> From: Paul Spencer
>>> Sent: Sat 2008-11-22 8:31 AM
>>> Subject: Re: [mapguide-internals] RE: Project Sponsorship
>>>
>>> I'm also in favour of this.  The OpenLayers team has just finished a
>>> lengthy discussion on sponsorship and has developed some guidelines of
>>> how the sponsorship stuff will work for them (largely based on the
>>> GDAL experience and example).  I think we will need to develop a
>>> similar set of guidelines for sponsorship for MGOS and have the
>>> community and the PSC discuss it before we can formally go that route,
>>> but the PSC could vote to agree (or not) on sponsorship in general
>>> with the details to be decided on later by a second vote.
>>>
>>>
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>
>>>
>>>
>>>
>>
>>
>>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals