On Thursday 16 March 2006 16:07, Alex Nordstrom wrote:
> Thursday, 16 March 2006 22:32, cobaco (aka Bart Cornelis) wrote:
> > On Thursday 16 March 2006 15:06, Alex Nordstrom wrote:
> > > No, bugs in Debian should be reported through the Debian BTS. That,
> > > incidentally, is what it's there for.
> >
> > BUT it's a lot more efficient al around for the user to file upstream
> > bugs upstream in the first place:
> > - it facilitates direct communication, having discussions through a
> > middleman is usually not constructive to having things fixed (and
> > will surely slow things down)
>
> That's one way of looking at it. The other way to look at it is that
> package maintainers generally have a better understanding than users of
> what information upstream maintainers look for in bug reports. They'll
> also have communicated with upstream in the past, which often means
> they have better rapport with them.
in the specific case of KDE this is a fallacy, KDE has people sitting
between KDE BTS and the developpers already (which is not implying that KDE
developers don't look in kde BTS, just that KDE does have non-developpers
focussing on bug-triage as a feature)
-> no need to add another layer to that picture
The above IME holds for most general purpose software.
> > Filing obviously
> > non-debian-specific bugs upstream instead of debian BTS is a
> > relatively easy way for ordinary users to make things easy on the
> > debian-kde team, leaving them more time to work on Debian specific
> > bugs (which improves things for everyone).
>
> How does one tell what is an "obviously non-Debian-specific bug"? Users
> rarely know which changes package maintainers make, and hardly ever
> have the means to get a picture of what impact those changes have.
> For example, in the issue in question here, without looking at the code,
> I can't say for sure that the problem isn't caused by, say, a
> configuration file holding the default printing time span that's not
> where it's supposed to be because the package maintainers changed its
> location.
there's no way to be 100% sure off-course, but we all have common sense. So
make a estimation: do you consider it probable the bug is an upstream bug?
if so file upstream. In this case I'd be surprised if it was a
debian-specific bug.
> > Exactly why do you have a problem with the _suggestion_ of filing
> > bugs like this upstream?
>
> Mainly because the suggestion neglected to mention that this is an
> ad-hoc workaround, not the way things *ought* to work.
They way things *ought* to work in Free Software is that everyone pitches in
to the best of his/her abilities (constraints being available time,
resources and skills). Freeloaders aren't prohibited, but shouldn't expect
special consideration either.
Given that, it seems logical to me to file bugs that appear to be
code-related upstream (most Debian packages try to minimise the diff with
upstream after all) and bugs that seem package-related with Debian.
Mistakes will (and undoubtfully do) happen, but filing them in the most
logical place will lead to the least work all around IMO.
> This thread has now brought out a more complete picture of the situation,
> which I think is good.
:)
--
Cheers, cobaco (aka Bart Cornelis)
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
Attachment:
pgp1dH5OIy2Va.pgp
Description: PGP signature