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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
