On Tue, Dec 18, 2007 at 02:47:14AM +0000, David Nusinow wrote:
> On Tue, Dec 18, 2007 at 12:47:39AM +0100, Bastian Venthur wrote:
> > Since I received a terrifying amount insults(!) via mail for not
> > implementing this feature request after my last blog entry, where I
> > asked for help developing rng, I'd like to make my position about this
> > issue clear.
> >
> > Why was I opposed to implement this.
> >
> > 1. I *personally* hated that some packages sent a *huge* amount of
> > unrelated info with every bugreport for this package, even if it's not
> > meaningful for this bugreport.
Is your bandwidth _that_ cheap ? I mean what is the point to stripping
informations for users that already send bad bug-reports where it could
actually save it ? Your reasoning totally eludes me.
> > I made a quick check against my favorite package with a very long
> > output and thought (and still think) that this info is not even
> > relevant for the majority of bugreports of this package. So I
> > thought it was not too much to ask, to write the reporter a friendly
> > mail to post the output of this script, if it's really needed.
It's pretty obvious that you don't package things with a very large user
base then. And given the numerous times where David, Julien or myself
explained to you why this assertion is wrong, well …
> > 2. I *personally* was very annoyed by packages with very long presubj
> > text, which I doubt anyone reads anyway. Since I don't want rng to be
> > annoying to the users, I decided to leave that feature away. An
> > implementation of this feature would mean to pop up a window with some
> > text the user should read before continuing to report the bug. I don't
> > like popups and don't want rng to make use of them.
>
> I haven't implemented presubj text in my patch, so this is a non-issue for
> that specifically.
I'd say that not showing presubj is as wrong. For the libc there is a
very usual bug about locales depends. We now have a presubj about that,
and we didn't had bug reports for libc 2.7 about locales. Meaning that
it works (we had ~10 for the 2.6). The locales package presubj has the
tremendous line count of *18* lines. What an aggression ! Its full
content is :
locales dependencies on glibc
=============================
If at some point (in unstable) you get messages like:
The following packages have unmet dependencies:
locales: Depends: glibc-2.6-1 which is a virtual package.
then please check for example on [1] that the glibc of the _same_ version as
the `locales` package you are trying to upgrade is in state _installed_ for
your architecture, and for how long.
If it's not, it is very likely that the corresponding libc has not been
built _and_ uploaded to the mirrors for your architecture yet, and that the
dependencies will be fixed soon. Please wait for the package to be installed
for more than 24 hours before reporting abug about `locales` dependencies.
[1] http://buildd.debian.org/~jeroen/status/package.php?p=glibc
And if you find the presubj's are too long, then bug the packages.
Your [bastian's not david's] reasoning is the same as saying "damn 10
Debian packages have too many debconf questions, let's make debconf
default priority ultra-high so that this 10 packages that I never
install anyway won't bug me with those questions". Huh ? Doesn't make
sense.
If the maintainer put a presubj (or anything else) then he felt it was
necessary. WHO THE HELL ARE YOU TO KNOW HIS JOB BETTER ?
> > 3. I'm definitely opposed to a feature which will pop up a *terminal*
> > where a user has to do something before he can proceed reporting a bug.
> > Sorry, but this won't happen in rng. I might consider such a thing if it
> > could be scripted to use QT or even GTK but a terminal popping up in a
> > GUI application is a no-go for me, sorry.
>
> For any script that is non-interactive the terminal will appear and then
> disappear once the script is done running. On my system it's barely
> noticeable. One thing that I'd be open to is modifying the standard so that
> scripts put something like #BUG_INTERACTIVE in the interactive scripts. We
> could trivially grep for this phrase, launch a terminal in this one case,
> or just run the script and get the output directly if this comment is
> absent. I don't know of any interactive bug scripts that currently exist,
> so this should be a fairly simple thing to require if people are willing
> (I've CC'ed -devel for opinions on this).
Such a script is the one from hibernate for example. Well, I would be
surprised if it was used for anything else than questions with yes/no or
even a string answer. It would be even better to provide some API that
rng could supersede that would be "sourced" from those scripts so that
it even doesn't starts a terminal, and rather show nice X11 queries. I
suppose using zenity for that may work e.g.
Though it would need to rewrite the couple of interactive scripts out
there, I'm sure it's not a lot to do.
> I've offered a partial solution for the terminal above. I think that
> neutering the interactive scripts is a horrific idea though. Users who can
> report bugs can handle having a terminal ask them a question or two.
This is pretty horrible indeed. Implementing alternative "reporbug"
tools is a great idea, but they should all support /usr/share/bug
scripts and files. That's the bare minimum.
> One alternate method is to require interactive scripts to use debconf,
> which should be a good middle ground because they've already used it during
> the install. We could check what frontend debconf is using, and if it
> requires a terminal we pop one up and if not then just let the gtk frontend
> do its thing. Again, this would be something other developers would have to
> agree to, but I think this is actually a better way to handle these sorts
> of scripts now that debconf is our standard for interaction.
This also makes sense.
> I've been nice, polite, and patient, so please stop implying that I've been
> otherwise. Rather than hurl insults I wrote, tested, and improved the patch
> for this. Several people have been interested in having this escalated to
> the tech-ctte, which I am willing to do, at which point it will no longer
> be a fully optional feature. I don't want to take this to the tech-ctte,
> but this issue really is that important. You might consider this an
> optional feature, but many of us do not. As for your limited time, I repeat
> my offer to upload this fix and ensure that it works, so you don't have to
> spend any time on it.
FWIW I've been disgusted at how this whole issue was dealt with, and
if a bug is sent to my packages that do have a presubj or scripts and
that the information isn't there or that the bug is a bug that the
presubj explicitely explained the user should not report, then the
report gets closed without notice. We have 100+ real *complex* hard bugs
to deal with on the libc right now, I don't have the time either to
fight with Bastians delusions or to triage politely bugs I should not
receive in the first place.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgprOerX6aVvr.pgp
Description: PGP signature