Re: Comments on Trac ticket mails
Alexander E. Patrakov wrote: [...] If the text is not US-ASCII and the content-transfer-encoding is quoted-printable, all non-ASCII bytes are converted to the =XY notation, where X and Y are hex digits. ASCII pats of the message are readable with vim this way, [...] So quoted-printable would be no problem as *LFS tickets are mostly US-ASCII and can therefore be pretty well understood if viewed in quoted-printable. Then we'd still have 7 bits during transport. Perfect readability with vim was not in my mind when I sent that message, but the ability to find out what the message is about (or run a grep on the mbox etc.) without starting the mail client can be useful sometimes. -- Nico signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
Gerard Beekmans wrote: It can be made more clear. And is the project name truly necessary in the Subject header. We already know which project a ticket belongs to based on the mailinglist it was sent to (this of course is me assuming most everybody uses separate email folders to filter email into. If you have all your LFS emails in one folder, than this topic distinction would be preferably for those people). Maybe a change that combines both and use the old Bugzilla Subject method: [LFS Ticket #abc] Summary here [BLFS Ticket #def] Summary here and so forth. We all know that it is about tickets, so we could drop that. What about the following? [LFS #1234] Useful subject lines [BLFS #] Handle ticket numbers with 5 digits or more [CLFS #4711] New build method Or even [LFS 1234] Useful subject lines [BLFS ] Handle ticket numbers with 5 digits or more [CLFS 4711] New build method I like your idea, too, Gerard. Playing devil's advocate here: how about 'mutt /var/mail/nico' rather than 'view /var/mail/nico'? ;-) Oh, yet another package to install ... mutt in addition to Thunderbird, not right now, thanks ... :-) -- Nico signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
Nico R. wrote: We all know that it is about tickets, so we could drop that. Always keep in mind, though, there's more people than us. If we make things clearer by adding a word or two, it's not always a bad thing. It's even more grammatically correct. That's not to say it always has to be that way. I personally have no real preference using something like [LFS Ticket #number] or [LFS #number]. I would keep the # symbol in it. Judging by the lack of responses (okay, granted, not much time has gone by yet) nobody really cares either way. How about we take a step back for a minute and figure out *how* to change Trac. Additionally, I have a comment on the Trac emails that I find more 'annoying' for lack of a better word: the From: header. Tickets are sent as From: Linux From Scratch [EMAIL PROTECTED]. Something similar happens with other project ticket emails. It would look better to include the word Trac in the From: header and abbreviate the project name too. From: LFS Trac From: BFLS Trac From: CLFS Trac If we were to go about it that way, including the project name in the Subject: header would be redundant. It could be shortened to Subject: [Ticket #number] Summary here. -- Gerard Beekmans /* If Linux doesn't have the solution, you have the wrong problem */ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
On 2/23/06, Nico R. [EMAIL PROTECTED] wrote: What about the following? [LFS #1234] Useful subject lines [BLFS #] Handle ticket numbers with 5 digits or more [CLFS #4711] New build method I like this the best. Combined with the From: field, I wouldn't have a problem figuring out it was a Trac ticket. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
Gerard Beekmans wrote: Judging by the lack of responses (okay, granted, not much time has gone by yet) nobody really cares either way. How about we take a step back for a minute and figure out *how* to change Trac. Indeed. You have to keep in mind how Trac parses its config files, what variables are available. Some of the suggestions put forth so far I'm sure are possible, but would take some serious hacking of Trac or the creation of our own Python plugin for Trac. It would look better to include the word Trac in the From: header and abbreviate the project name too. From: LFS Trac From: BFLS Trac From: CLFS Trac Yes, we could do this. It could be shortened to Subject: [Ticket #number] Summary here. If we did what you suggest above, the Subject would be (I think): [LFS Trac] #number: Summary -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
Indeed. You have to keep in mind how Trac parses its config files, what variables are available. Some of the suggestions put forth so far I'm sure are possible, but would take some serious hacking of Trac or the creation of our own Python plugin for Trac. Any serious hacking seems a bit silly in this case. It's not all that critical to spend that kind of time on it. If (some of the suggestions) are easy to take care of, let's go for it. If we did what you suggest above, the Subject would be (I think): [LFS Trac] #number: Summary Close enough for me. -- Gerard Beekmans /* If Linux doesn't have the solution, you have the wrong problem */ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
Gerard Beekmans wrote: [LFS Trac] #number: Summary Close enough for me. Alright. I'll test a couple of changes... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
Alexander E. Patrakov wrote: If the text is not US-ASCII and the content-transfer-encoding is quoted-printable, all non-ASCII bytes are converted to the =XY notation, where X and Y are hex digits. ASCII pats of the message are readable with vim this way, but non-ASCII requires Mutt. If viewability with vim is an absolute requirement, use the 8bit content-transfer-encoding. Looking through the python code, it appears I can set the variable [mime_encoding] to be either 'base64', 'quoted-printable', or 'none'. 'base64' is assumed unless you specify something else. 'none' will be regarded as ASCII only, and if the script encounters any non-ASCII characters, it will bail. I'm not sure how likely it is to encounter non-ASCII chars. Perhaps if someone includes them in their comments? What's the best thing to do here? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
On Thu, Feb 23, 2006 at 08:34:11AM -0700, Gerard Beekmans wrote: If we did what you suggest above, the Subject would be (I think): [LFS Trac] #number: Summary Close enough for me. I think what was meant was this (this is a cut and paste of mutt's index pane): 3 N 23/02.15:52 BLFS Trac #45: Gnome 'sploded lots and scared my kitt 4 N 23/02.11:17 LFS Trac#12: Thingy go boom 5 N 23/02.11:16 LFS Trac#1: It no workee unless the thingamugug is 6 N 23/02.10:45 Jeremy Huntwork +- 7 N 23/02.08:34 Gerard Beekmans Re: Comments on Trac ticket mails I could be wrong. Nifty idea though. Kevin -- Kevin Lyda diamond kevin is my comic idol [EMAIL PROTECTED] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
kevin lyda wrote: 3 N 23/02.15:52 BLFS Trac #45: Gnome 'sploded lots and scared my kitt 4 N 23/02.11:17 LFS Trac#12: Thingy go boom 5 N 23/02.11:16 LFS Trac#1: It no workee unless the thingamugug is 6 N 23/02.10:45 Jeremy Huntwork +- 7 N 23/02.08:34 Gerard Beekmans Re: Comments on Trac ticket mails I could be wrong. Nifty idea though. In Trac's Notification emails, what you see in the brackets is the name of the project. So to have [LFS Trac] means that our project name is 'LFS Trac'. (This value also appears in the title section of all web pages.) Trac sticks this in the Subject line (and the From field), and the ticket number and description always follow the project name. This is handled deep in the core of Trac's notification code. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
kevin lyda wrote: I think what was meant was this (this is a cut and paste of mutt's index pane): 3 N 23/02.15:52 BLFS Trac #45: Gnome 'sploded lots and scared my kitt 4 N 23/02.11:17 LFS Trac#12: Thingy go boom 5 N 23/02.11:16 LFS Trac#1: It no workee unless the thingamugug is 6 N 23/02.10:45 Jeremy Huntwork +- 7 N 23/02.08:34 Gerard Beekmans Re: Comments on Trac ticket mails I could be wrong. Nifty idea though. Total removal of the word ticket in the subject header doesn't look bad at all looking at it the way you presented it. Btw, love your ticket summary lines. -- Gerard Beekmans /* If Linux doesn't have the solution, you have the wrong problem */ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
Gerard Beekmans wrote: That's not to say it always has to be that way. I personally have no real preference using something like [LFS Ticket #number] or [LFS #number]. I would keep the # symbol in it. My preference would be [?LFS $number]. Tickets are sent as From: Linux From Scratch [EMAIL PROTECTED]. Something similar happens with other project ticket emails. It would look better to include the word Trac in the From: header and abbreviate the project name too. From: LFS Trac From: BFLS Trac From: CLFS Trac This would be good. If we were to go about it that way, including the project name in the Subject: header would be redundant. It could be shortened to Subject: [Ticket #number] Summary here. I wouldn't like that as well. It makes it harder to write rules to sort the email if info is in different headers. I would prefer to have the subproject abbreviation in the Subject: header. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
I wouldn't like that as well. It makes it harder to write rules to sort the email if info is in different headers. I would prefer to have the subproject abbreviation in the Subject: header. Why couldn't you filter on the From: header if it ends up containing the subproject's name? To include it in both seems redundant -- Gerard Beekmans /* If Linux doesn't have the solution, you have the wrong problem */ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
On Thu, Feb 23, 2006 at 11:20:02AM -0500, Jeremy Huntwork wrote: If the text is not US-ASCII and the content-transfer-encoding is quoted-printable, all non-ASCII bytes are converted to the =XY notation, where X and Y are hex digits. ASCII pats of the message are readable with vim this way, but non-ASCII requires Mutt. If viewability with vim is an absolute requirement, use the 8bit content-transfer-encoding. Looking through the python code, it appears I can set the variable [mime_encoding] to be either 'base64', 'quoted-printable', or 'none'. 'base64' is assumed unless you specify something else. 'none' will be regarded as ASCII only, and if the script encounters any non-ASCII characters, it will bail. I'm not sure how likely it is to encounter non-ASCII chars. Perhaps if someone includes them in their comments? What's the best thing to do here? IMO, use quoted-printable; here's why: 1) The vast majority of characters in bug reports will be 7-bit ASCII. Even if we do allow other character sets in the submission form (which AFAIK we do), most of the characters that get typed in will be valid 7-bit ASCII (English letters and Arabic numerals). 2) 'Base64' is totally unreadable unless you have a mail client available, or you know how to decode base64. Yes, most people have a mail client available most of the time, but if there's another option that doesn't break something else, but which does still allow most of the mail to be read without a mail client, I'd go with that other option. 3) 'None' will die if the user puts in a non-ASCII character. IMO, that's not good. Whether the users will try it or not is another question, though. (Additionally: What if we start adding bugs regarding the UTF-8 support, after it gets officially put into the book? Those bug reports will almost assuredly require more than 7-bit ASCII, at least for some characters. More than zero. OTOH, we can change this setting later, too.) 3) 'Quoted-printable' will avoid failing in the case of a non-ASCII character. It'll still be mostly readable without a mail client, though (because most characters are 7-bit ASCII) -- IMO, that's the best of both worlds. I would also say that viewability with Vim is nice but not absolutely required; that's why I wouldn't recommend hacking Trac to support 8bit. (I use Vim once in a while instead of Mutt, too. But not often, because I do have Mutt installed.) pgpPgKfm2ObRT.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Comments on Trac ticket mails
I noticed two things in the many mails I'm receiving from the Trac ticket system: 1. The subject lines always start with the full project name in square brackets and the ticket number. Example subject: [Linux From Scratch] #1715: bash-3.1.010. This is unfortunate, because when the subject can't be displayed completely by the mail reader, most messages look pretty much the same to me, example when there are replies to them: Re: [Linux From Scratch] #1715: bas... I suggest changing the subject prefixes to LFS, BLFS, ALFS etc. to improve this. 2. The main part of a Trac mail is always encoded in UTF-8, and sent with Content-Transfer-Encoding: base64. This is ... well, this may *usually* be quite reasonable. It is possible and not harmful to encode mails in UTF-8 even if they only use US-ASCII (since UTF-8 is a superset of US-ASCII). However, if such mails are sent base64-encoded, you don't want to do a view /var/mail/nico to have a quick look at them when bash tells you that you have new mails. ;-) And it increases message size. I haven't checked the relevant standards right now, but AFAIK it should be possible to send UTF-8-encoded texts with content-transfer-encoding quoted-printable. This would make more sense here, since most (if not all) of the text is US-ASCII anyway. (And if the standards didn't allow it, you could simply send US-ASCII instead of UTF-8 where possible.) You all may think that these two points are very minor (and you are probably right), but right now, I find them to be highly annoying. :-| Cheers, -- Nico signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
Nico R. wrote: This is unfortunate, because when the subject can't be displayed completely by the mail reader, most messages look pretty much the same to me, example when there are replies to them: Re: [Linux From Scratch] #1715: bas... I suggest changing the subject prefixes to LFS, BLFS, ALFS etc. to improve this. While you started the subject a second adjust that could be made is making the subject clearer that we are dealing with a bug here. Sure, all of us know exactly what this subject line means and the #xyz indicates a ticket ID to us. It can be made more clear. And is the project name truly necessary in the Subject header. We already know which project a ticket belongs to based on the mailinglist it was sent to (this of course is me assuming most everybody uses separate email folders to filter email into. If you have all your LFS emails in one folder, than this topic distinction would be preferably for those people). Maybe a change that combines both and use the old Bugzilla Subject method: [LFS Ticket #abc] Summary here [BLFS Ticket #def] Summary here and so forth. such mails are sent base64-encoded, you don't want to do a view /var/mail/nico to have a quick look at them when bash tells you that you have new mails. ;-) Playing devil's advocate here: how about 'mutt /var/mail/nico' rather than 'view /var/mail/nico'? right now, but AFAIK it should be possible to send UTF-8-encoded texts with content-transfer-encoding quoted-printable. This would make more sense here, since most (if not all) of the text is US-ASCII anyway. (And if the standards didn't allow it, you could simply send US-ASCII instead of UTF-8 where possible.) What happens in cases where text is *not* US-ASCII and still sent with the content-transfer-encoding set to quoted-printable? Maybe nothing happens. I admit to knowing next to nothing about character sets in this way. -- Gerard Beekmans /* If Linux doesn't have the solution, you have the wrong problem */ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
Gerard Beekmans wrote: Nico R. wrote: This is unfortunate, because when the subject can't be displayed completely by the mail reader, most messages look pretty much the same to me, example when there are replies to them: Re: [Linux From Scratch] #1715: bas... I suggest changing the subject prefixes to LFS, BLFS, ALFS etc. to improve this. While you started the subject a second adjust that could be made is making the subject clearer that we are dealing with a bug here. Sure, all of us know exactly what this subject line means and the #xyz indicates a ticket ID to us. Yeah, this value is configurable. I'm not sure if it's possible (or more accurately, how difficult it is) to use dynamic values here. AFAIK, it's just a string. So [xLFS] would probably work for each project. I'll let you guys discuss it further. What happens in cases where text is *not* US-ASCII and still sent with the content-transfer-encoding set to quoted-printable? Maybe nothing happens. I admit to knowing next to nothing about character sets in this way. Not my strong suit either. :/ -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
Gerard Beekmans wrote: What happens in cases where text is *not* US-ASCII and still sent with the content-transfer-encoding set to quoted-printable? Maybe nothing happens. I admit to knowing next to nothing about character sets in this way. It is perfectly legal to set content-transfer-encoding to 8bit, something like this: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This depends on the mail server that correctly handles 8-bit messages (i.e. practically anything). Then one can view the mail spool with vim. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
Gerard Beekmans wrote: What happens in cases where text is *not* US-ASCII and still sent with the content-transfer-encoding set to quoted-printable? Maybe nothing happens. I admit to knowing next to nothing about character sets in this way. If the text is not US-ASCII and the content-transfer-encoding is quoted-printable, all non-ASCII bytes are converted to the =XY notation, where X and Y are hex digits. ASCII pats of the message are readable with vim this way, but non-ASCII requires Mutt. If viewability with vim is an absolute requirement, use the 8bit content-transfer-encoding. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
on Wednesday, February 22, 2006 at 7:56 Gerard Beekmans wrote: Maybe a change that combines both and use the old Bugzilla Subject method: [LFS Ticket #abc] Summary here [BLFS Ticket #def] Summary here and so forth. If I may suggest, the stuff in the square brackets isn't usually the most important (which is what one wants to see first) stuff anyway. So, *if* it's a benefit to put it in at all, why not _post_pend it instead of _pre_pend it, ie Summary here [LFS Ticket #abc] Summary here [BLFS Ticket #def] and so forth. $0.002 R -- http://www.quen.net Pay your own bills. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
R.Quenett wrote: So, *if* it's a benefit to put it in at all, why not _post_pend it instead of _pre_pend it, ie Summary here [LFS Ticket #abc] To be honest, it looks odd. Also if a subject line is truncated in an email program due to space constraints, [LFS Ticket] may not appear. Only seeing a summary may not be enough to distinguish a bug update from something different. If you wanted to look at it from a grammatical point of view, the topic of the subject line is it being a ticket so that designation should come first. The summary is a descriptor. -- Gerard Beekmans /* If Linux doesn't have the solution, you have the wrong problem */ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comments on Trac ticket mails
Nico R. wrote: You all may think that these two points are very minor (and you are probably right), but right now, I find them to be highly annoying. :-| No problem. The suggestion to look at these issues is reasonable. We'll see what we can do. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
