Please note: +the mingw‑w64 and MSYS2 projects are not, +in any way, affiliated with MinGW.org; +MinGW.org does not support the products +of these projects. +

General Enquiries

If you encounter a problem using MinGW, or MSYS, +and you cannot find a satisfactory answer on our web‑site, +in our +mailing‑list archives, +or elsewhere on the internet, +or if you simply need some advice relating to MinGW, or MSYS, +then we advise you to +subscribe to the MinGW‑Users mailing‑list, +and ask. +

Do please note that, to help avoid spam, +this mailing‑list is open to subscribers only. +Please do not +attempt to circumvent the subscription process, +by sending mail to either the mingw-users-owner, +or the mingw-users-admin addresses. +Doing so will be of no benefit to you, +since subscription is free‑of‑charge in any case, +and you will get no reply from the former address, +while the latter is reserved for automated self‑help replies, +in response to specific subject keywords. +

Before posting to this mailing‑list, +we strongly recommend that you acquaint yourself with +the mailing‑list posting etiquette; +compliance with this may improve your chances of receiving a response, +whereas non‑compliance may result in your post being ignored. +

Reporting Bugs

After discussing an issue on the mailing‑list, +as described above, you may be asked to file a formal bug report. +(Alternatively, +if you are certain that you have identified a bug in a MinGW.org product, +you may choose to file such a bug report of your own volition; +however, if you choose this course of action, +please be aware that many bug reports, +which are filed without prior discussion, +are ultimately dismissed as user error). +

Before you even consider filing a bug report, +please review +the list of existing tickets, +(including closed tickets +— ensure that the “Open” and “Closed” +status check‑boxes are both selected, +and click the “Search” button), +to ensure that the issue has not already been reported. +

Please do not file a bug report, +if your issue relates to an unimplemented API feature; +it is more appropriate to file +a “Feature Request” instead. +

Please do not waste your time, (and ours), +reporting issues with your anti‑virus software; +the heuristic nature of such software, all too frequently, +results in false‑positive reports, +and in the absence of deterministic evidence of infection, +we will take no action in response. +

Regardless of your motivation for filing a bug report, +you must, (unless you already have one), +create a personal OSDN.net account, +and you should also +acquaint yourself with the bug reporting guidelines. +You may then +log in to your OSDN.net account, +and proceed to +the bug report submission form. +Please review the submission instructions, +(which appear at the top of the submission form), +then complete the form, +leaving the ticket type set to “Issue”. +

Please do not ignore the submission instructions. +In particular, note that, +unless you are a member of the MinGW.org Project development team, +you are not authorized to assign a specific responder +for the ticket; nor are you authorized to assign an elevated priority +or severity attribute for your ticket. +If you exceed your authority, +your ticket will be reassigned to lowest +priority/severity, and may even be rejected altogether. +

Before you finally submit your report, +please use the “Preview” facility to check for, +and correct, any markup errors; +(these are, alas, all too common, +and create a bad impression of the reporter). +Finally, when you are satisfied, click the “Submit” button +to complete the ticket submission process. +

Feature Requests

When you wish to request the implementation of a new feature, +(e.g. to support a currently unsupported MSVC or POSIX API function), +you should file a feature request ticket. +The procedure is effectively the same as that for +filing a bug report, +except that you set the ticket type to “Feature Request”, +instead of leaving it as “Issue”. +

Please be aware that feature request submissions are subject +to the same restrictions on your authority, +as are applicable to bug reporting. +

Before you submit a feature request, +it is recommended that you discuss the feasibility of implementing +the proposed feature, as a general enquiry topic, +on the mailing‑list. +Additionally, after you have submitted such a request, +you should use the mailing‑list to bring it to the +attention of the MinGW user community, +and invite them to support your request, +by voting on your ticket; +(please note that MinGW developers will consider votes, +when prioritizing feature requests). +

MinGW.org’s preferred method for communication, +between users and the project team, is by way of mailing‑lists. +Historically, there were several topic‑specific lists, originally +hosted on SourceForge.net; +today, only two remain operational, and both are +hosted on OSDN.net. +

Operational Mailing‑Lists

Historical Mailing‑List Archives

In earlier days of the project history, +the volume of mailing‑list traffic was significantly greater +than it is today. +This traffic was distributed over five topic‑specific +mailing‑lists, of which only the two identified above +remain operational today; +the other three historical lists, which are identified below, +are now closed, and it is no longer possible to subscribe, +or to post messages to them. +However, archives of historical postings remain +available on SourceForge.net, +and may be searched using their respective keyword‑search boxes, +below. +

Mailing‑List Posting Etiquette

MinGW is an open source project. +As such, it is heavily dependent on people who dedicate +their spare time to the goals and continuing development of the project, +so please keep this in mind when posting to the mailing‑list. +

Before you post, you are advised to +acquaint yourself with the following commonly accepted guidelines, +with which you are strongly encouraged to comply, +when composing your posts. +Failure to comply with these guidelines may result +in your posts being ignored by a number of knowledgeable people, +and repeated offenses may even lead to your posts being vetted, +and potentially rejected, by the list moderator. +

The language of the lists is English ; +if you post in any other language, you are unlikely to elicit a response. +
Do search the mailing list archives, +(both the current archives, and those of the historical topic‑specific +lists), before posting, (see the links associated with each of the lists above); +many questions have already been asked and answered. +
Do use +a meaningful subject line. +A subject line should include a pertinent few words summarizing +the subject of the email; +(when one replies to emails, +one should always make certain the subject line of the email is still +relevant to the reply). +In particular, if you receive list mail in digest format, +do always +set the subject back to the original text, +from the message to which you are replying. +Do not reply with a subject of +“Re: MinGW-??? Digest no. ???”; +such replies are prime candidates for deletion, without being read. +
Do post in a MIME format with +“Content-Type: text/plain”. +Do not post as HTML, or in any other MIME format, +(and in particular, do not use multi-part MIME, +with plain text duplicated as HTML); +some list subscribers are unable to, or choose not to read such mail, +and will be unable or unwilling to answer you. +
Do not +post messages with very long lines of text; +except when pasting screenshots, where line wrapping might lead to confusion, +ensure that lines of running text are wrapped with hard line breaks, +at a length of between 65 and 72 characters. +
Do quote sections of the original text, +and interleave your replies to individual points, +below the relevant context. +Do not +top-post; +(this +treatise +explains why top-posting is considered unacceptable). +
Do trim out sections of the original mail, +which are not required to establish the context of your reply. +(Once more, +this is particularly important when replying to mail received in digest form; +do reply +to one subject at a time, +and do remove all content related to other subjects). +Do not persistently recycle irrelevant junk, +quoted from earlier messages in the thread. +
Do not +include “legal mumble” signatures. +You are posting to a list that will be read by thousands of users, +and anything you say will be archived in the public domain; +in this context, such drivel in your signature is neither enforceable, +nor meaningful. +
Do not hijack an existing topic thread, +when you wish to introduce an unrelated subject; +(i.e. do not reply to an existing message, +when your reply is unrelated to the original subject). +When you want to introduce a new topic, plainly start a new thread, +(i.e. a completely new message). +Replying in an existing thread confuses mail readers +and humans who are trying to participate in the original discussion; +it is a sure way to irritate other subscribers, +and will likely get you ignored, +if not even black-listed. +

Historical information on netiquette may be found in +RFC-1855. +

This +article, +(also available +here), +offers valuable advice on how to ask questions, +in a manner most likely to elicit useful replies. +