cppget.org | Mailing Lists

Posting guidelines go in here.

users@cppget.org   Archives | Subscribe | Unsubscribe

General mailing list for the cppget.org package repository. Questions, bug reports, suggestions can all be sent here.

announce@cppget.org   Archives | Subscribe | Unsubscribe

Read-only, low-volume announcements mailing list for the cppget.org package repository. Note that additions/migrations/removals of individual packages are not announced here, only general repository changes (policies, etc).

Subscription and Posting Guidelines

You can post without subscribing, however, you emails will have to go through a moderator and may take a little longer to appear. While some members may insist on list-only replies, we keep everyone CC'ed and you should get replies without subscribing.

Also note that the mailing lists are public and with public, searchable archives that will be available forever. If you post from your company's email address, everyone will know you work there. If this is a concern, post from a personal/anonymous address, such as Gmail. And don't ask us to remove any mentioning of you from the archives; this is not easy and we won't be able do it.

Speaking of Gmail, Google routinely marks mailman subscription confirmations as spam or promotion, so check those folders after subscribing. If you are not happy with this state of affairs, write to your senator, I mean, Google.

When posting, please observe the following guidelines (with TL;DR in bold). Some of them may appear arduous to you but think about it this way: by following them, you help the person trying to help you and thus increase your chances of getting a quick and helpful reply (plus, some years later, you won't be embarrassed reading your own emails).

1. When replying, keep the mailing list CC'ed in your reply. This way other subscribers who may have had a similar issue can provide you with a solution. Plus, questions and answers will be archived and available to others with similar questions in the future.
2. Do not send a new question by replying to an existing message. It will end up with an unrelated subject (or, even worse, with a digest subject) and this makes email clients with support for threading as well as the mailing list archives less usable. Instead, create a new email with a new, descriptive subject.
3. Choose a descriptive subject for your post. Examples of bad subjects: "Quick question", "Problem", "Help me", "SOS!!!". Examples of good subjects: "Error compiling foo.cxx with Clang 3.7", "Unable to use feature X to achieve result Y".
4. When replying, remove unnecessary content of the old message. Leave just enough to indicate what part you are replying to (remember, the original message is available in full in the archives). Top-posting is the worst.
5. If reporting a problem, specify all the relevant package and environment information. This includes the package version, operating system name and version, C++ compiler name and version, command lines used, and the exact diagnostics observed. If it is a crash, a stack trace would also be very helpful. Generally, the more details you provide, the less the person trying to help you will have to guess and assume.
6. Do not send images with screenshots of errors. Instead, describe what happened in the email text. For example: "When trying to run foo, I got the 'Assertion Failed' dialog which indicates that the failure occurred in file foo.cxx line 123. The message says: 'Invalid NULL pointer'".

   In the same spirit, don't use fancy HTML coloring/formatting to describe the problem since this will be stripped either by the mailing list software or the recipient's mail client. A detailed description in plain text is always the best bet.

7. Preferably no attachments, strictly no .zip. If sending sample source code, test inputs, logs, etc., unless it is fairly small (say, less than 20KB), prefer to upload the archive on the Web somewhere and put the URL into your post. If it is really small, just attach it to the email, uncompressed.

   Whether attaching or uploading, make sure that you do not include generated source code, object files, libraries, or executables in your archive.

   If you have to attach the archive to the email, use archive formats for which open-source decompression tools are widely available, such as .tar.gz, .tar.bz2, and .tar.xz. In particular, do not use .rar. While .zip also satisfies this criteria and is the only format supported by Windows out of the box, most malware these days is sent as .zip archives. As a result, our mail servers (and those of many other organizations) simply reject any mail that contains .zip attachments. So if you are only able to create a .zip archive, then you will have to upload it.