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 translations....then 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 > pace....and, 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). However, > please let me point that we currently cannot translate these debconf > notes because, as far as I can see, the "switch to po-debconf" bug is > not fixed (I'm surprised that you mention it to be fixed, indeed). > > You seem to have understood that some kind of lazyness from > translators is involved. I'm afraid this is mostly because I did not > make my point clear on that topic. We do not request for less work, we > actually suggest that our work has some use and interest for the > Debian users, which is, in our opinion, not the case for low priority notes. > > > Aside from all this, I'm afraid that we would have....wording > improvement suggestions to make to the debconf templates...:-). I'm > pretty sure that, given the context, there is a very little chance > that you would consider them, but the current wording is not very well > adapted to all situations (I suggest trying to set debconf to use the > "Gnome" interface and then "dpkg-reconfigure -plow qmail-src" to see > the problem). > > > > > > Now please ... for the love of Buddha ... leave me alone about this. I > have > > better things to do with my time than flame with you about this. > > > I don't want to point fingers, but the flame did start mostly because > you closed the bug without any discussion..:-)... > > I am now very glad to see that we can discuss even if we're probably > not agreeing still (which, again, is not my point. I insisted because > I thought until yesterday that you were refusing dialog). > > And, I even learned something in this thread, which I should remember: > Joey Hess is *not* the designer of the debconf protocol..:)
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. 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." 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. 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. Any ideas? Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
