Re: Forwarding bugs upstream
Hi, John:
On Thursday 13 January 2011 19:25:59 John Goerzen wrote:
> On 01/12/2011 09:35 AM, Gunnar Wolf wrote:
[...]
> But still, let's say that a Debian developer has X minutes to spend on
> Debian a day.
Let's be true: it's not that a Debian developer has X minutes to spend but
that a Debian developer *wants* to spend X minutes. Probably same end result
but wildly different motivations.
> What kinds of tasks that the developer does will add the
> most value to Free Software or benefit the most people to the greatest
> degree?
>
> * Working on Debian packaging
>
> * Fixing bugs that are within their scope/ability
>
> * Working on documentation
>
> * Cut-and-paste monkey with upstream BTSs
Managing information, always managing information. Remember: information is
power. First information, then everything else.
In your proposed scope that means:
1) Working on *a* Debian packaging: Without *a* Debian package wouldn't be
bugs for it, would it? But pay attention to the "a" within "a package": it's
of no value (worse than that: it's of negative value) working on new packages
when the already packaged ones are not in good shape (I'll limit my scope to
packages maintained by the same person: it seems to me that there are some
Debian Maintainers -really and luckily a true minority of them, that seem to
be trying to break a record in that they maintain a bazillion of them but
when you look at those packages bug records they have bugs from back to the
day Armstrong footed the Moon. That's of no good).
2) Cut-and-paste monkey with upstream BTSs (for those bugs worth to do it):
that will allow for you to parallelize your effort and more bugs will be
corrected in a given time. If any, bugs you (properly) pass to the upstream
developer are bugs that will cost you not a dime of your valuable time from
them on.
3) Working on documentation (including documenting which bugs are your working
on, which bugs will be dealt with later and which bugs have a known
workaround or you just won't even try to fix and why): properly informing
about your intentions and the real state of your packages will reduce the
rate that bugs come in and will relax your users so they'll be more kind to
you... or at least, it will allow you to say RTFM (or RTF bug reports, or RTF
FAQ) and be with it.
4) Fixing bugs that are within their scope/ability.
I know this will seem quite counterintuitive but yes, fixing bugs is the
lowest of your priorities. If you understand what I said, good; if you
didn't, please, make me the honour of considering me as an authority and act
accordingly (and by act accordingly I mean ala popperian, consider my
reasonements as the less valuable of your knowledge chain but still
valuable).
> Some of what you've suggested above could be accomplished by the DD
> telling the user, "Here, include this info in your bug report and get me
> back in the loop if you need me."
Regarding bugs, the first priority of a package maintainer should always be to
be able to reproduce it and once he is able to reproduce it, taking the user
out of the loop (except for timely informing him of his advances) till the
bug is properly solutioned.
> This is a special case of more general communication problems. It is
> rarely a good idea to have a gatekeeper in place between people that are
> capable of communicating already.
Once the package maintainer is able to reproduce the bug, odds are he will be
the most capable one to properly care about it.
> If the user is not capable of producing cogent answers and a useful bug
> report, even when asked for specific details, this user is unlikely to
> produce a useful bug report for upstream. But the user is also unlikely
> to produce a useful bug report for Debian.
Then, after proper time and effort you will find yourself in the position of
honestly close it with a "non-reproducible" tag.
> I don't see my task as a
> maintainer to provide education to the user on how to read standard
> logfiles, use the command line (when relevant), etc.
Why not? You want to provide Debian with good packages and the end user with
valuable software, don't you?
>
> This is a particular problem with Bacula. There are many users that are
> unable to distinguish between a configuration mistake or
> misunderstanding on their part and a bug.
I know your pain: being there, seen that, got the t-shirt. But you are in the
great situation of being able to tell them RTFM without pain nor remorse. Do
it as needed.
> I imagine this phenomenon
> exists in any sufficiently complex package that takes users out of their
> existing comfort zone. If it's clear to me that it's not a bug, I'll of
> course close it and point them to the Bacula users mailing list.
That should be OK... once you tell the user "out of all my knowlege it seems
to be a configuration problem, please treat it accordingly".
> Sometimes it is unclear immediately whether they have discovered a bug
> or not, but it is quite clear that they don't understand how to
> configure Bacula and would need a tremendous amount of handholding to
> get to the point where we know if there's even a bug or not.
If you don't like our parties, you are free not to come here. In other words:
if you find Bacula to be too hard a package to deal with you are free to
orphan it. After all, packaging it for yourself won't take you any more
effort than packaging it for Debian, will it? But if you want to package it
for Debian, do what it takes to do it properly.
> Again I
> try to push these to bacula-users. If someone asks me a question I know
> the answer to off the top of my head, I'll answer, but I never promised
> to provide free tech support by maintaining Bacula ;-)
That's exactly what you (impliclty) promised -if only just to Debian users.
Cheers.
Reply to: