Anne Wilson wrote: > On Wednesday 24 June 2009 01:41:07 Kevin Kofler wrote: >> I know what distribution packagers do, I am a Fedora KDE packager. And we >> ask users to report their bugs upstream unless there is evidence that >> they're specific to Fedora. The vast majority of bugs which are reported >> to us are NOT specific to Fedora, they're upstream bugs. Also note that >> we don't even have that many patches, we try to stay as close to upstream >> as possible. > > This is contrary to what I've been told. It's not a black or white thing, and often depends on case-by-case factors, including who you're dealing with, the severity of the issue at hand, etc... > I always recommend trying to ascertain whether other distros also see the > problem, and to report it upstream if that seems to be so. If it is not > possible to ascertain that I was told that it should in the first instance > be reported to the distro, who will then pass it upstream if relevant. Here's my quick $0.02: When distro maintainers (fedora kde-sig) ask reporters to upstream issues, it is usually at the point where it is strongly believed to not be a distro-specific issue. For issues the team deams critical and reproducible, sure, we'll usually take the reigns from there. Otherwise, our usual sop is also, to ask reporters to upstream issues themselves. And even then "Upstream" here sometimes has varying meanings, from "ask on upstream mailing list" (similar to checking other distros) to reporting on upstream bug trackers. The moral of my story is to prevent issues languishing downstream indefinitely, to avoid the kind of comment "this bug has been around forever, why is it still a problem and not fixed?", which does no one any good, esp when upstreams aren't made aware of the issues (which, by all accounts so far, seems to be what happened here in this particular dovecot/kmail case). Hopefully this clarifies things, as I see it. I don't mind continuing to discuss the details of how all this happens, and how best to share the burdens of bug reporting, followup, reproducibility, triage, etc... Actually, I'd invite such dialog, to make things better for everyone involved.