[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

> 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.


Reply to: