And that is one of the biggest issues customers can't quite understand. A BUG is something that acts in opposition to an application's documentation. If un-documented, then security risks play a role as well as some common sense workflow assessment.
An RFE is a request to change a documented feature in an application, or add a new feature. Simply disagreeing with a value (3GB for example in ext3), doesn't make it a bug. I haven't read through all of the BZ's you've posted, but the ones I did have time to look through were sorely lacking in information. If you say something doesn't work right, point to the documentation where it says differently. Or point to a lack of documentation. In short, be a contributor, and not just a consumer. That, more than anything else, will draw attention to bugs when you file them. Also, think upstream first. It was mentioned previously, but it bears repeating. If you file a bug with Red Hat, they have to figure out what you're talking about, then look upstream and file a bug there and get the community to agree to add/alter the code so we can then pull it back down into our products. Like any community, if more than one group points something out it is more likely to happen. So if you report something, and then Red Hat comes looking for the same thing, there is a lot more grease on the wheels. HTH -jduncan On Mon, May 25, 2015 at 8:08 AM Tom H <[email protected]> wrote: > On Sat, May 23, 2015 at 11:45 PM, ToddAndMargo <[email protected]> > wrote: > > On 05/23/2015 03:46 PM, Tom H wrote: > >> > >> AFAIR, the kvm bugs that you reported were RFEs. > >> > >> Within a release, RH's very conservative when considering RFEs and > >> rarely if ever does it do apply them; by default, it only fixes "real" > >> bugs. > > > > I was being polite. And not all of them were reported as RFE's. > > You might not have reported them as RFEs but they effectively were. >
