Is it fair to day that in general that bugs should not be filed for application issues? I'm working on documentation and it sems to me we need some rough criteria for filing bugs. Esoteric application errors are something we can do little about, and I susoect when people do this they are not reporting them upstream where they may be fixed. Of course if it is a bug that afects our users and would generate questions and/or cause us to delay an upgrade is always an exception just to name one, but esoteric application bugs that don't affect other apps at all don't seem to be a good idea, especially if the user neglects to report it upstream. Do others agree that for bug filing guidelines that bugs for MacPorts should generally be confined to installation and configuration issues, with exceptions roughly spelled out? I'm not saying it is a big problem but still I think some rough guidelines like this would be a good thing. It is better than stating nothing and then marking bugs "invalid" immediately because people get sorta miffed. Mark
On 2006-10-10 23:10:37 -0700, Mark Duling wrote:
Do others agree that for bug filing guidelines that bugs for MacPorts should generally be confined to installation and configuration issues, with exceptions roughly spelled out?
Yes, but if a patch exists upstream, then one may want the patch to be included in the port, in particular if the bug is important and releases aren't done much often. Examples: * vorbis-tools: the bug has been there for more than a year. https://svn.macosforge.org/projects/macports/ticket/10821 (the patch may be important in languages with non-ASCII characters, as the bug affects both reading and writing ogg files). * MPFR: we don't do releases much often, as this requires testing on many architectures, and we are often very busy. But patches are provided on the web page. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
participants (2)
-
Mark Duling
-
Vincent Lefevre