Ok, my two cents on the matter. I am still new enough to the community to be considered an outsider, so here is an outsider's perspective. I hope not to step on toes, but it will probably happen anyway.
First: Cosmetic things, i.e. user interface issues, pretty pictures, and things that effect the overall look and feel. If they do not stop the program from functioning, they are not high priority. It may be agitating to look at, but it is not a bug. However, This does not prevent you from putting in feedback, or even working on patches to change the offending behavior. Just don't expect cosmetic issues to be high priority to anyone other than the person submitting the feedback. There honestly are things out there that are thoroughly broken that need to be repaired first. I am guessing however that in the case of emerge, if you understand python (or even know enough to pick through the code a bit) that you can probably fix the issue yourself, and submit the fix. :-) Second: Bug reports for real bugs. Bug reports need to be thorough. If they do not provide enough information to reproduce a bug, or at least explain exactly what is going on, then it is hard for the developers and bug squashers to do anything about it. It may seem to you like they are "not doing their job" by not researching it, then conceder this. When you submit a bug, it is YOUR bug, not theirs. You have the primary responsibility for making sure they know what you are talking about. In the case listed in this thread, when the second bug was submitted including a more thorough description, and the research that had been done, it was taken care of promptly. A bug report is a good thing, but if they can't reproduce it, and don't have enough information to know what the problem is, they can't fix it. Third, and maybe most important: Configuration Issues. Many developers try to make sure to cover as many bases as they can when it comes to developing their software. For many applications, the vast majority of users will have a fairly standard setup. While this is not always the case, you need to conceder that many open source and free software applications are written first and foremost for the needs of the author. While this may sound a little callous or selfish, remember one thing. Free And Open Source Software is developed by volonteers, who also have real world jobs and lives. They develop tools that make their lives easier, and they share. They do not all have thousands of dollars to spend on investigating every possible platform that their program may be expected to run on. Mounting your config files for firefox from a coda file system is far from standard in anyone's books. If you know how to add that functionality without breaking anything that is already there, then write the patch and submit it. If not, then submit a thurough bug report, or a general request in the appropriate forums or mainling lists. Let them know exactly what your problem is, and what you would like done. Be polite, and be patient. If they do not bite the first try, it is not a personal snub. Most of us have never run into problems with firefox. And honestly, if the idea of creating a new profile would not work for you, then recreating your firefox directory, with "physical" copies of the symlinked files would do the trick as well. I know that does not address the issue of running the Config files from a coda system, but it would get things working under normal circumstances. I have lurked long enough to see a number of posts complaining about the bug Tracking system. In most cases the people complaining were hateful and said very little that was useful. They generaly stuck to name calling and the like. This is not to say they all did, but most. :/ I am sure that eventually I will have to submit a bug, and I may find myself having to hold my tongue to apply what I have seen here, but I will try to be understanding about it. To be honest, this is probably not the forum to complain about bug reports. Complaining about bugs is probably not bad though. It might be a good source of feedback to see if other people are having the same problem, or at least to get a general idea of how to format and word your bug before you actually submit it. ^_^ Basic summary: There are a lot of tools at your disposal. Know them, use them, love them. :) If you have problems with one of those tools, by all means ask questions. :) The Free Software and Open Source communities are run primarily by volonteers. Remember that when you are deciding how to approach them. Imagine if you just sunk three years into a project, and suddenly someone started attacking you because it didn't work perfectly on their system. Remember, bug reports take time. Track your bug, update your bug, make sure to keep the bug propperly fed or it might die. -- [EMAIL PROTECTED] mailing list
