Bugs/issues for the MapServer source code (or msautotest) should be submitted through github at https://github.com/mapserver/mapserver/issues . Bugs/issues related to documentation or the demo server should be submitted through github in the docs repository at https://github.com/mapserver/docs/issues . You will first need to create a free personal account at github (https://github.com/plans).
Please keep the following issues in mind when submitting a bug/issue:
Security/vulnerability reports should not be submitted through Github, but instead please send your report to the email address: mapserver-security nospam @ osgeo.org (remove the blanks and “nospam”).
Set a meaningful yet reasonably brief title of your ticket.
In your description please indicate whether you built from source or got it from an prepared binary build, and specify the MapServer version.
Search existing issues/tickets, as well as the MapServer mailing lists for related discussions (through Nabble) before submitting the ticket.
Do not use Github to ask questions, which should always be sent to the Mailing Lists instead.
Include concise steps to reproduce the issue.
The most important thing when reporting a bug is to boil down a minimum example that is needed to reproduce the bug. That means a minimal mapfile + any data files it depends on. Remove everything from the map file that isn’t needed to reproduce the bug.
The developers often dislike having to spend the first 30 minutes working on a bug, having to fix paths, remove unnecessary layers, removing references to external symbols or fonts that were not included or even needed and otherwise doctoring your test case to get it to a point when they can actually use it.
If the bug is easily demonstrated with « shp2img », without the need to setup a proper web service and test it through http, then please show it that way. If a standalone MapScript script can demonstrate a problem without it having to be a web service, likewise submit it that way. Please include the commands that you used to reproduce the issue in a simple commands.txt file.
The chances of a bug being addressed in a timely manner is directly related to the speed with which the developer can reproduce the bug. If you make that hard for the developer, chances are the bug will be given up on or ignored for quite a while.