Bug#388952: qmail-src: [annoying_notes] Abuse of debconf note(s)
Package: qmail-src Version: N/A Severity: normal Hello, As announced in http://lists.debian.org/debian-devel/2006/09/msg00630.html, this bug report is part of a mass bug filing campaign about the "abuse" of debconf templates of type "note". First of all, in case you fixed you package in the short timeframe that happned between my announcement and this bug report, please accept my apologies and, of course, feel free to ask me to close the bug report...or just close it yourself. One or more template(s) has/have been identified in qmail-src debconf templates and an automated analysis mentions that it/they is/are displayed to users at low or medium priority. The debconf-devel(7) manpage makes it clear that the "note" type should be used only for important notes that the user really should see. On the other hand, the "low" priority is meant for very trivial items that have defaults that will work in the vast majority of cases. The "medium" priority is meant for normal items that have reasonable defaults. As such, a note should only be used for IMPORTANT stuff, so actually all debconf notes should be priority highor should not exist. Please consider one of the following options: - move the text of the debconf note to the README.Debian file. The drawback is that the text will not be translatable anymore, which will be worked in the future. However, given that your note is very rarely displayed, this is indeed not a very strong drawback - move the text to NEWS.Debian. This option should however rather be reserved for future texts of the same kind as the contents of this file is only displayed when users upgrade the package - change the template type to "error" in case this note is meant to be displayed only in some cases when a problem shows up during execution of the maintainer's scripts. Please check debconf-devel(7) for details - raise the priority to "high". This should be the last option to consider. It should be used only in cases where you judge that the information you display is VITAL for users of your package and that one could NOT USE IT if not reading the note. A dedicated check will be proposed to the lintian and linda package maintainers so that future uses of low and medium priority note templates will be discouraged in the future. So, if you wish you package to be lintian-clean, then you need to fix this..:-) Template(s) identified in your package: qmail-src -- config:7 qmail-src/build -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17-2-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388952: qmail-src: [annoying_notes] Abuse of debconf note(s)
reopen 388952 tags 388952 wontfix thanks > I don't know what this holy war is all about, but I disagree. Unless there is > an absolute policy change that will force the qmail-src package out of the > distro, I'm not changing it. Please don't use too strong words just to express your disagreement, and please leave room for discussion instead of just closing it. This is why I reopen this bug report and (hopefully temporarily) tag it "wontfix". I won't reopen it if you close it again, but I ask you to consider leaving time for discussion. The bug report tried to explain why using low and medium priority notes is usually considered as a bad idea, even by the designer of the debconf protocol. The thread that starts at http://lists.debian.org/debian-devel/2006/09/msg00438.html gives the whole rationale and I suggest you consider some of the followups to my announcement. More precisely http://lists.debian.org/debian-devel/2006/09/msg00443.html The default priority for debconf is high. This means that medium and low priority messages are not displayed to users of default installs. On the other hand, notes in debconf are designed and explicitely suggested to be used for information that is important enough for being displayed by debconf during the package installation or configuration and, indeed, stop the installation process. Choosing a low priority indeed means that you consider that information to be not very importantand in such case, it is suggested to use something else than debconf notes. This is the whole point of this mass bug filing. Mass bug filing are not holy wars, but rather an attempt to help maintainers to improve their packages. It is usually enough work to keep this for important enough stuff. In that specific case, the Debian translators are trying to lower the load induced by (sometimes very long) debconf notes which indeed prove to be essentially useless. signature.asc Description: Digital signature
Bug#388952: qmail-src: [annoying_notes] Abuse of debconf note(s)
user debian-i18n@lists.debian.org usertag 388952 + no-cooperation thanks > I could argue my case with you, but I see no point in it. If you have gone > through all the trouble to do a massive bug posting against most likely > countless hundreds of packages, you will stand your ground and refuse to > capitulate no matter how sound my logic, or articulate my debate. Why are you assuming that at least I won't listen to your arguments? As I explained, doing a mass bug filing is certainly not something that one does without prior thinking, given the amount of work involved. Up to now, you have not given a single explanation about your motivations to not follow the suggestion I am giving here. So you don't even give me a chance to understand why you refuse that change and thus improve the MBF process. So far, your only point in this argument has been "oh yes it is" just like in a famous Monty Python sketch which I can point you to if you're too young for this culture. I don't exactly call this negotiating but rather arguing (*this* reference is a little bit more recent). > If this holy jihad continues, I will seek other remedies as afforded by the > Debian social contract. I'm afraid that *you* are insulting. Or at least, you want to be insulting. Unfortunately, it seems that your deep ignorance of the exact meaning of the word "jihad" in the muslim culture prevents you from understanding that I should feel honored by this word. So, indeed, thank you for using it...this is really appreciated. I would indeed be really glad to see what would happen if you choose "the other remedies offered by the Social Contract"...but, dear, I'm afraid I already know the result and I don't really like when fellow developers feel ridiculous. signature.asc Description: Digital signature
Bug#388952: qmail-src: [annoying_notes] Abuse of debconf note(s)
Quoting Christian Perrier <[EMAIL PROTECTED]>: > user debian-i18n@lists.debian.org > usertag 388952 + no-cooperation > thanks > > > > I could argue my case with you, but I see no point in it. If you have gone > > through all the trouble to do a massive bug posting against most likely > > countless hundreds of packages, you will stand your ground and refuse to > > capitulate no matter how sound my logic, or articulate my debate. > > Why are you assuming that at least I won't listen to your arguments? > Why do I assume so much? As a direct result of your actions. All you do is keep whining that I have not capitulated to your demands without so much as a reason why. I gave you my reason. I disagree with you, and that is all. > > If this holy jihad continues, I will seek other remedies as afforded by the > > Debian social contract. > > I'm afraid that *you* are insulting. Or at least, you want to be > insulting. > > Unfortunately, it seems that your deep ignorance of the exact > meaning of the word "jihad" in the muslim culture prevents you from > understanding that I should feel honored by this word. So, indeed, > thank you for using it...this is really appreciated. I see what you're trying to do, and I won't take the race bait. Your inner struggle is exactly that ... A struggle with yourself. Get down off your high horse, and think about what you're doing before you do it. Waging war on the rest of the Debian community is not the way to fix a distribution that is already in horrible dis-repair. It is people like you that keep Debian the laughing stock of the open source community. > I would indeed be really glad to see what would happen if you choose > "the other remedies offered by the Social Contract"...but, dear, I'm > afraid I already know the result and I don't really like when fellow > developers feel ridiculous. I'm sure you understand that feeling quite well. Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388952: qmail-src: [annoying_notes] Abuse of debconf note(s)
> > Why are you assuming that at least I won't listen to your arguments? > > > > Why do I assume so much? As a direct result of your actions. All you do is > keep whining that I have not capitulated to your demands without so much as a > reason why. I gave you my reason. I disagree with you, and that is all. I'm afraid I'm not "whining". I'm asking you about your reasons for not considering the suggestion. I really, and sincerely, would like to understand why you're doing what we call in French "un procès d'intention", ie assuming that someone has secret hidden intents. What I hear up to now is "I disagree". What I'd like to hear is not you saying "I agree" but rather "I disagree because this, that, etc.". Please help me improving my rationale on that topic and if you feel that I'm completely wrong, please help me understand why > > > > If this holy jihad continues, I will seek other remedies as afforded by > > > the > > > Debian social contract. > > > > I'm afraid that *you* are insulting. Or at least, you want to be > > insulting. > > > > Unfortunately, it seems that your deep ignorance of the exact > > meaning of the word "jihad" in the muslim culture prevents you from > > understanding that I should feel honored by this word. So, indeed, > > thank you for using it...this is really appreciated. > > I see what you're trying to do, and I won't take the race bait. Your inner > struggle is exactly that ... A struggle with yourself. Get down off your high > horse, and think about what you're doing before you do it. Waging war on the I actually wonder why reporting what one considers a bug should be considered a "war". I can't believe you actually belong to the vanishing population of developers who understand bug reports as physical agressions. You have maybe been hurted by some of the wording in the initial bug report. This is perfectly understandable and, if you please accept to believe me, is more because of a loose English on my side than a real intent to hurt a fellow developer's feelings. > rest of the Debian community is not the way to fix a distribution that is > already in horrible dis-repair. It is people like you that keep Debian the > laughing stock of the open source community. I really don't understand that sentence. Do you mean that caring about details is not a quality of the Debian community? We are here talking about something you could consider a detail: your code is meant to display information to users.but this information is very rarely displayed and, in a near future, will never be displayed at all. This information is marked as translatable by yourself which means you're implicitely asking Debian translators to work on it. My intent, as Debian i18n task force coordinator, is to make the best use of the very scarce resources we have. So, indeed, if something has really little chances to be used, we would prefer it not be offered for work. As a compromise, would you consider removing the translatable status of the offending note? (additionnel useless and counter-productive rant deleted) signature.asc Description: Digital signature
Bug#388952: qmail-src: [annoying_notes] Abuse of debconf note(s)
First of all, thank you, Jon, for giving me more input on the background of your reaction to this bug report. I was actually not asking for more and I regret that we went in this long argument. Please also note that this mail has been initially written before Manoj and Joey mails yesterday. I delayed it because it was not completely finished. I still want to send it in the hope that you'll read it. I personnally consider that we made progress in the dialog, from my POV. > The mere act of a mass bug-filing is in effect the first volley in a war > against > the developers affected. I hate these mass bug filings over something as > trivial as the severity of a message. Some people consider this trivial. Some others don't. Long time ago, when debconf was introduced and several maintainers jumped on it for this and that, many users have been complaining about Debian installs being constantly interrupted by long and verbose notes and questions. Only a very long and patient work hand in hand with maintainers has helped improving this and some mass bug filings have been involved. > > These messages are marked low because they are low priority. They > should not be seen by power users, but should be seen by someone who > wants to know every little thing. > > This is why I am annoyed ... That reasoning is perfectly understandable and this is indeed an opinion that some developers share. The majority, however, does not share this opinion and tend to think that notes to users should not be displayed during package installs and do more pertain to documentation like README.Debian. Most part of your reaction seems to come from a bad timing in suggestions you received for your package (first switch to debconf, then switch to po-debconf to allow translationsthen finally some jerk suggesting you that your debconf stuff is useless...:-)) I may understand that and we should take this as the infortunate part of a MBF: sometimes we just come at the wrong moment. Point taken, definitely. However, no MBF is indeed requesting that the issue is ugently fixed. In that specific case, we already know that this is a long-term work and that every maintainer will handle this at his|her own paceand, even, take time to discuss with the bug reporter about the issue and bring more context. > Now I get a bug from you complaining that the severity of my messages is too > low, forcing you to do more translation work, when it was someone in the user > base that specifically asked me to enable such a thing. Actually, the "someone" (Thomas) who sent the "switch to po-debconf" suggestion could perfecly have been the same "someone" who sends you the "please remove notes" bug report. Thomas does a regular survey of packages using debconf and not po-debconf and systematically reports this to their maintainers (the requirement for po-debconf should become a requirement for etch+1, thus making the issue RC). He usually does not always look closer inside the package code to detect whether the use of debconf fits "philosophy" of the protocol (in short, not abusing notes). > > It's this constant power struggle within Debian of "enforcing standards" over > this little thing, that little thing, and everything in-between that slows > down > our release cycle, and brings attention away from real issues like bugs that > -*actually*- affect the usability of the system. Spending time rewriting Well, this is part of the package maintenance. No packaging is perfect and we all slowly improve it by learning this or that specific part we were previously ignoring or misunderstanding. > debconf rules because someone decided that they don't like low priority note > messages, is in my opinion, a waste of time. Those messages are low for a > specific reason: so they can be ignored. If I wanted everyone to have to read > them over and over again, I would have marked them with a higher priority. I What I'm explaining you in this bug report is that using a low priority mostly makes the messages invisible to your package users...which is also a waste of your time because you certainly took great care writing them...:-). Hence the suggestion to move this in a more convenient place. I also point, in the BR, that the debconf protocol will quite probably ignore the "note" type in the future (please get in touch with Joey Hess to get confirmation of this). This would make these notes completely invisible and I'm afraid that the wasted time would be even greater. > There aren't that many messages in qmail-src, and if I remember correctly, the > number is less than five. You have spent more time and energy arguing with me > pointlessly over this crap than it would have taken to translate the miniscule > number of messages into several different languages. I am only a native > English speaker, and do not want to do any translation myself for fear of > improper translations. Certainly. That's the job of translators (myself included). How
Bug#388952: qmail-src: [annoying_notes] Abuse of debconf note(s)
Quoting Christian Perrier <[EMAIL PROTECTED]>: > First of all, thank you, Jon, for giving me more input on the > background of your reaction to this bug report. > > I was actually not asking for more and I regret that we went in this > long argument. > > Please also note that this mail has been initially written before > Manoj and Joey mails yesterday. I delayed it because it was not > completely finished. > > I still want to send it in the hope that you'll read it. I personnally > consider that we made progress in the dialog, from my POV. > > > The mere act of a mass bug-filing is in effect the first volley in a war > against > > the developers affected. I hate these mass bug filings over something as > > trivial as the severity of a message. > > Some people consider this trivial. Some others don't. Long time ago, > when debconf was introduced and several maintainers jumped on it for > this and that, many users have been complaining about Debian installs > being constantly interrupted by long and verbose notes and questions. > > Only a very long and patient work hand in hand with maintainers has > helped improving this and some mass bug filings have been involved. > > > > > > These messages are marked low because they are low priority. They > > should not be seen by power users, but should be seen by someone who > > wants to know every little thing. > > > > This is why I am annoyed ... > > That reasoning is perfectly understandable and this is indeed an > opinion that some developers share. The majority, however, does not > share this opinion and tend to think that notes to users should not be > displayed during package installs and do more pertain to documentation > like README.Debian. > > Most part of your reaction seems to come from a bad timing in > suggestions you received for your package (first switch to debconf, > then switch to po-debconf to allow translationsthen finally some > jerk suggesting you that your debconf stuff is useless...:-)) > > I may understand that and we should take this as the infortunate part > of a MBF: sometimes we just come at the wrong moment. Point taken, > definitely. > > However, no MBF is indeed requesting that the issue is ugently > fixed. In that specific case, we already know that this is a long-term > work and that every maintainer will handle this at his|her own > paceand, even, take time to discuss with the bug reporter about > the issue and bring more context. > > > Now I get a bug from you complaining that the severity of my messages is > too > > low, forcing you to do more translation work, when it was someone in the > user > > base that specifically asked me to enable such a thing. > > Actually, the "someone" (Thomas) who sent the "switch to po-debconf" > suggestion could perfecly have been the same "someone" who sends you > the "please remove notes" bug report. > > Thomas does a regular survey of packages using debconf and not > po-debconf and systematically reports this to their maintainers (the > requirement for po-debconf should become a requirement for etch+1, > thus making the issue RC). He usually does not always look closer > inside the package code to detect whether the use of debconf fits > "philosophy" of the protocol (in short, not abusing notes). > > > > > > It's this constant power struggle within Debian of "enforcing standards" > over > > this little thing, that little thing, and everything in-between that slows > down > > our release cycle, and brings attention away from real issues like bugs > that > > -*actually*- affect the usability of the system. Spending time rewriting > > Well, this is part of the package maintenance. No packaging is perfect > and we all slowly improve it by learning this or that specific part we > were previously ignoring or misunderstanding. > > > > debconf rules because someone decided that they don't like low priority > note > > messages, is in my opinion, a waste of time. Those messages are low for a > > specific reason: so they can be ignored. If I wanted everyone to have to > read > > them over and over again, I would have marked them with a higher priority. > I > > What I'm explaining you in this bug report is that using a low > priority mostly makes the messages invisible to your package > users...which is also a waste of your time because you certainly took > great care writing them...:-). Hence the suggestion to move this in a > more convenient place. > > I also point, in the BR, that the debconf protocol will quite probably > ignore the "note" type in the future (please get in touch with Joey > Hess to get confirmation of this). This would make these notes > completely invisible and I'm afraid that the wasted time would be even > greater. > > > There aren't that many messages in qmail-src, and if I remember correctly, > the > > number is less than five. You have spent more time and energy arguing with > me > > pointlessly over this crap than it would have taken to translate the > miniscule
Bug#388952: qmail-src: [annoying_notes] Abuse of debconf note(s)
> Well .. if notes are going away, that's something entirely different. > > I looked at the .config file in question, and I have three notes. > > I have a warning message that is marked as high, a message that tells the user > how to actually build the package, which is medium, and I check for the > presence of another essential package and display a warning if it is missing. qmail-src/build could either be considered important enough to have its priority raised to high...or could maybe move to README.Debian. Considering that users who install qmail-src probably already know that they will have to do something special to get the qmail binary, I'd probably suggest moving that one to README.Debian The same probably goes for the qmail-src/warning for about the same reasons. qmail-src/ucspitcp could be considered an "error" and thus use the "error" template type. Such "error" templates are recommended to be used in situation where a previous check verifies whether some conditions are fulfilled or not. > > The reason it was coded that way, was that I read this in the packaging manual > at http://www.debian.org/doc/packaging-manuals/debconf_specification.html: > > "note This template is a note that can be displayed to the user. As > opposed to > text, it is something important, that the user really should see. If it is not > possible to display it, it might be saved to a log file or mailbox for them to > see later." In the discussion that lead to the mass bug filing, Joey Hess mentioned that this has been abandoned (at least partlyIIRC debconf only mails "critical" notes, or so...better ask Joey directly. > This tells me that note is exactly what I want to use to display info to the > user. This is the entire reason I implemented debconf in the first place, was > to display messages to the users. If that is not going to be possible > anymore, > I will have to switch back to dumping the messages to the console. > > If I don't include the message that you have to take an additional step to > actually build a binary qmail package, most users won't figure it out, don't > know where the readme files, and will simply get frustrated and either > complain > about it or file a bug. Well, your package description is saying: "Source only package for building qmail binary package". From my POV, it makes very clear that installing this package will *not* give you a working qmail but you'll have to do some other actions to have it running properly (namely compile it). It is my understanding that users who will install this package will be some kind of power users...at least powered enough to go looking in /usr/share/doc/qmail-src > I could change the type to text, which will have no effect on the end users > experience, but would remove the evil note. I just need to force the user to > see the message, and click OK. I don't really care if it's a note, text, > whatever. I just need them to see it, and acknowledge it. That's all. "error" type could be considered appropriate as an alternative to README.Debian even if we're not exactly speaking about an "error" I can't promise that noone will criticize this later, thoughprobably with the rationale that wanting to display this information in all cases could be considered as too strong. signature.asc Description: Digital signature
Bug#388952: qmail-src: [annoying_notes] Abuse of debconf note(s)
Quoting Christian Perrier <[EMAIL PROTECTED]>: > > > Well .. if notes are going away, that's something entirely different. > > > > I looked at the .config file in question, and I have three notes. > > > > I have a warning message that is marked as high, a message that tells the > user > > how to actually build the package, which is medium, and I check for the > > presence of another essential package and display a warning if it is > missing. > > qmail-src/build could either be considered important enough to have > its priority raised to high...or could maybe move to README.Debian. > > Considering that users who install qmail-src probably already know > that they will have to do something special to get the qmail binary, > I'd probably suggest moving that one to README.Debian > > The same probably goes for the qmail-src/warning for about the same > reasons. > > qmail-src/ucspitcp could be considered an "error" and thus use the > "error" template type. Such "error" templates are recommended to be > used in situation where a previous check verifies whether some > conditions are fulfilled or not. > > > > > > The reason it was coded that way, was that I read this in the packaging > manual > > at http://www.debian.org/doc/packaging-manuals/debconf_specification.html: > > > > "note This template is a note that can be displayed to the user. As > opposed to > > text, it is something important, that the user really should see. If it is > not > > possible to display it, it might be saved to a log file or mailbox for them > to > > see later." > > In the discussion that lead to the mass bug filing, Joey Hess > mentioned that this has been abandoned (at least partlyIIRC > debconf only mails "critical" notes, or so...better ask Joey directly. > > > This tells me that note is exactly what I want to use to display info to > the > > user. This is the entire reason I implemented debconf in the first place, > was > > to display messages to the users. If that is not going to be possible > anymore, > > I will have to switch back to dumping the messages to the console. > > > > If I don't include the message that you have to take an additional step to > > actually build a binary qmail package, most users won't figure it out, > don't > > know where the readme files, and will simply get frustrated and either > complain > > about it or file a bug. > > Well, your package description is saying: "Source only package > for building qmail binary package". > > From my POV, it makes very clear that installing this package will > *not* give you a working qmail but you'll have to do some other > actions to have it running properly (namely compile it). > > It is my understanding that users who will install this package will > be some kind of power users...at least powered enough to go looking in > /usr/share/doc/qmail-src > > > I could change the type to text, which will have no effect on the end users > > experience, but would remove the evil note. I just need to force the user > to > > see the message, and click OK. I don't really care if it's a note, text, > > whatever. I just need them to see it, and acknowledge it. That's all. > > > "error" type could be considered appropriate as an alternative to > README.Debian even if we're not exactly speaking about an "error" > > > I can't promise that noone will criticize this later, > thoughprobably with the rationale that wanting to display this > information in all cases could be considered as too strong. > > > Unfortunately, you're giving the users far too much credit. I have had to deal with bug reports for issues far more trivial than that. I do, however, run into some bright people every now and then. I'll just go ahead and just remove all the debconf prompts all-together, I'm sick of having to argue about it. If people get pissed off about it, I will direct them to you. Expect a new qmail-src shortly. Will that end this once and for all? Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388952: qmail-src: [annoying_notes] Abuse of debconf note(s)
> I'll just go ahead and just remove all the debconf prompts all-together, I'm > sick of having to argue about it. If people get pissed off about it, I will > direct them to you. Expect a new qmail-src shortly. Will that end this once > and for all? Well, end it, sure. The only correction I'll made is that my point was not necessarily the removal of these debconf notes but certainly converge, along with you, towards the best possible solution. As I explained in detail in my former mail, this could have been through the use of high priority notes for some of them, removal for some others, or change to "error" for others. I'll certainly be happy to explain users who are missing the explanations in README.Debian in your package why these informations are not displayed at the package install. In any case, I will not nag you anymore, Jonit's perfectly clear to me that I nagged you enough for now. I hope that we'll have opportunities to collaborate on other occasions, maybe in better initial conditions. As a matter of fact, let's take this last mail as a "beer|other_beverage promise" if, by some life hazard, I would come through the place you physically live or you do the same by coming around the Paris, France city. That would be a good opportunity for me to prove you that I'm not only a white knight on a big white horse who fights Evil Maintainersand certainly for you to prove me that you're not the Evil Maintainer I indirectly mentioned in my first reactions in this thread (for which I apologize). signature.asc Description: Digital signature
