Dimi Paun wrote:
Just telling folks like me to shutup and report upstream will do no-one any good. Vast majority of folks will simply give up (and thus we lose a lot of valuable feedback), and you will simply get a lot of disgruntled users.
I wrote some similar complaints a year or two ago, there was some discussion about it being nice if Bugzillas talked to each other or some other kind of meta bug reporting. Maybe there is a way to bring in external upstream people on to the RHAT Bugzilla and sort of outsource the bugs for the upstream project while it remains hosted at RHAT's central Bugzilla since it was reported on a Fedora ticket.
We can complain upstream, but we need to feel that Red Hat is behind us. Otherwise, we all know that its just a big waste of time. Especially when we're talking about GNOME. Nothing changed in their elitiste attitude. It is one of the most frustrating experiences, why would you subject your customers to it?
I also felt at that time that RHAT should bang the drum upstream for the bugs that annoyed me. Where it would do some good is where the RHAT folks are already inside the upstream and understood there as contributors, eg, the kernel and xorg where the relationship is bidirectional and quite strong. But for a lot of packages that's not so much the case, a Redhat guy turning up on the upstream mailing list as the representative for grumpy users would require a lot of time and tact and be a pretty thankless task. Evolution seems to be a case in point, if the upstream project has gone all floppy then unless RHAT are going to airlift para-developers into it, someone from Redhat representing myriad problems might not pay off. I can see why it makes people say "go there yourself and champion your bug" because really RHAT doesn't owe us the work.
Maybe all one can hope for is that the Fedora packager, since he would be relatively familiar with at the least the structure of the project, might want to spend some time managing RHAT bugzilla complaints with the upstream for those projects, and that the upstream is ready for that.
Description: S/MIME Cryptographic Signature