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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101140150.52952.jesus.nava...@undominio.net
