I don't want to spoil your mood, but...
Build and compilation errors are often caused by a user's local configuration or environment. Such errors should not be reported. Report only compilation errors when they can be reproduced by others. Check by asking in forum or mailing list first.
1. How do you realistically expect from someone having problems with the build yet have sufficient knowledge to realize whether or not it can be reproduced by others?
2. In my own experience, errors during building of FPC and/or Lazarus from the trunk in 99.9% cases is caused by recent SVN commit, which carelessly broke one of few targets (perhaps, similarly to the issue you are mentioning). This can be quite frustrating for non-FPC developers, especially to figure out in which recent revision the problematic code was committed. Few breakages were, apparently, expected, but many simply look like a developer didn't test the patch on local machine (or did, but just one target or only with some default flags), submitted it to SVN and forgot about it. These issues sometimes get fixed really fast, but others can take few days, even when there IS a report for it on bugtracker.
Please let other FPC developers know that everyone's work is very important, valuable and greatly appreciated by the community. However, when you submit a patch to SVN, there could be a great number of people who will update and get their environment broken, if you don't test your patch locally first. Testing locally doesn't mean just running "make clean all", but actually building the whole trunk for at least Windows and Linux, both 32-bit and 64-bit, preferably also ARM. Scripts can be very helpful there too - you can just run a script, which will do the build for some common targets. On a typical today's desktop machine this wouldn't take more than 15 minutes, but will spare every other developer of frustration and time waste trying to figure out who broke what.
Crash-bug reports should always have a debugger backtrace with them. Especially the ones that happen only sometimes and are hard to reproduce need a backtrace always.
Ideally yes, but realistically, there are some targets and platforms, where getting backtrace can be very difficult (or impossible without proper tools). Embedded platforms come to mind. Also, not every user would have enough experience to get the backtrace. Nevertheless, I myself as a developer would really appreciate a bug report, even without backtrace - after all, this is better than nothing.
Some developers get angry when a customer submits bug report, but really this shouldn't be the case, especially with an open-source project. After all, a person cared enough for your product to spend time writing bug report, even if it's a duplicate (you can't expect every user to be a proficient bug-tracking software user too), not to mention that it could be a potentially real bug, fixing which will make the product even better - this kind of feedback is really valuable and should be appreciated. Sure, linking duplicate reports is also a time-waste, but in my opinion, it's a trade-off for an extra testing effort you get.
Opening lots of reports for a sub-system which is in alpha-state or otherwise not maintained is bad.
But...Why??! For example, "Alpha release" on
Wikipedia is described as:
The alpha phase of the release life cycle is the first phase to begin software testing (alpha is the first letter of the Greek alphabet, used as the number 1). In this phase, developers generally test the software using white-box techniques. Additional validation is then performed using black-box or gray-box techniques, by another testing team. Moving to black-box testing inside the organization is known as alpha release.[2]
Alpha software can be unstable and could cause crashes or data loss. Alpha software may not contain all of the features that are planned for the final version. In general, external availability of alpha software is uncommon in proprietary software, while open source software often has publicly available alpha versions. The alpha phase usually ends with a feature freeze, indicating that no more features will be added to the software. At this time, the software is said to be feature complete.
So, it looks like alpha release is actually meant for testing. Considering that in an open-source community, users are testers themselves, why wouldn't you want people to report bugs on that? Sure, these can be left unattended for quite some time, but isn't
a known issue better than
unknown issue?