Description of problem: Currently if you update the 'Doc Text' field for a bug, the email notification gets formatted in the same before/after format as any other metadata field associated with the bug. This is generally fine since metadata fields data is typically very short. The 'Doc Text' field is different though - it is expected to contain significant amounts of text - it is much more like a general bug comment. The email notifications you currently get look like this Laine Stump <laine> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |laine Doc Text| |Cause: | | | |When a virtual guest had a | |network interface that was | |connected to an SR-IOV | |Virtual Function (VF) using | |macvtap "passthrough" mode, | |and from there to an | |802.1Qbh-capable switch Doc Text| |shutting down the guest | |would cause the Physical | |Function (PF) associated | |with the SR-IOV device to | |be taken offline. Here is | |an example of the type of | |interface that would be | |affected: | | | | <interface type='direct'> | | | | <source dev='eth7' Doc Text| |mode='passthrough'/> | | <virtualport | |type='802.1Qbh'> | | <parameters | |profileid='test'/> | | </virtualport> | | </interface> | | | |Consequence: | | | |If the PF was being used by | |the host for its own | |network connectivity Doc Text| |host networking would be | |disabled whenever the guest | |was shut down (or when the | |guest's network device was | |detached) | | | |Fix: | | | |This problem was caused by | |libvirt erroneously taking | |down the PF instead of the | |VF. That bit of code has | |been Doc Text| |fixed. | | | |Result: | | | |When a guest using macvtap | |in passthrough mode to | |connect to an | |802.1Qbh-capable switch is | |shut down, the PF | |associated with the VF used | |by the macvtap connection | |now continues to work. This formatting is just horrific to view, and does not help you view the before/after differences. It would be desirable if the email could just present the new Doc Text separately from the 'before/after' table, just like it would for a comment. Or alternatively use the unified-diff format for showing it. eg +Cause: + +When a virtual guest had a network interface that was connected to an SR-IOV Virtual Function (VF) using macvtap "passthrough" mode, and from there to an 802.1Qbh-capable switch, shutting down the guest would cause the Physical Function (PF) associated with the SR-IOV device to be taken offline. Here is an example of the type of interface that would be affected: + + <interface type='direct'> + <source dev='eth7' mode='passthrough'/> + <virtualport type='802.1Qbh'> + <parameters profileid='test'/> + </virtualport> + </interface> + +Consequence: + +If the PF was being used by the host for its own network connectivity, host networking would be disabled whenever the guest was shut down (or when the guest's network device was detached) + +Fix: + +This problem was caused by libvirt erroneously taking down the PF instead of the VF. That bit of code has been fixed. + +Result: + +When a guest using macvtap in passthrough mode to connect to an 802.1Qbh-capable switch is shut down, the PF associated with the VF used by the macvtap connection now continues to work. This would actually make the emails for this change readable Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. File a bug 2. Write a few paragraphs of text in the 'Doc Text' field & submit 3. Actual results: Get a email alert formatted to make very hard to read the changes Expected results: A nicely formatted email of the changed text Additional info:
Douglas: Any objections to this change?
Hi Eliska, would you be able to take ownership of this change request, see what ECS members on the team would prefer (Martin, Mirek, Tomas, all CCed, and others), and present our view on it at our meeting on Tue., 23 April? After that we'll comment on this bug. Thanks, Silas.
Thanks Douglas for pointing me in the right direction. By the way, the change I am proposing is to just show the new text. I think this makes more sense, and makes it a lot easier to read.
Hi Simon, we have discussed this issue in the team and here's what we've got: 1. One of the ideas to make changes to Doc Text clearer to peruse was to repurpose and improve the colored diff code that formats patches, for example at: https://bugzilla.redhat.com/attachment.cgi?id=636932&action=diff However, the most useful diff of a BZ description would compare the text on a word-by-word basis (see GNU Wdiff), which I'm not sure the current code could do. We are also not sure if it is at all feasible to easily enhance the history page with colored diffs of Doc Text... What are your thoughts on such a feature? Our less ambitious plan contains a couple of proposals that we believe might also work as a solution: 2. In the BZ history page, such as https://bugzilla.redhat.com/show_activity.cgi?id=955520 the changes to Doc Text are sometimes split into several fields. We are not sure if there's a character limit, or commas and newlines are used to split the text. We propose to change the front-end rendering to display the Doc Text history entries always in a single field. 3. For emails, we propose to format changes to the Doc Text field the same way BZ comments are formatted, see the example below. There is only one additional feature request - to add a highlighted keyword about the change to Doc Text: *added* or *updated* or *removed* ======email start John Doe <jdoe> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Doc Text *updated* --- When a virtual guest had a network interface that was connected to an SR-IOV Virtual Function (VF) using macvtap "passthrough" mode, and from there to an 802.1Qbh-capable switch, shutting down the guest would cause the Physical Function (PF) associated with the SR-IOV device to be taken offline. --- Comment #1 from Dude McPants <dmp> --- A BZ comment goes here... =======email end Thank you for considering these ideas, Tomas
(In reply to comment #4) > 1. One of the ideas to make changes to Doc Text clearer to peruse was to > repurpose and improve the colored diff code that formats patches, for > example at: ... > the history page with colored diffs of Doc Text... What are your thoughts on > such a feature? Not going to happen unfortunately. The default is text only e-mails, which kinda makes coloured diffs hard. If the default was HTML e-mail, I may have a different opinion on this one. > Our less ambitious plan contains a couple of proposals that we believe might > also work as a solution: > > 2. In the BZ history page, such as > > https://bugzilla.redhat.com/show_activity.cgi?id=955520 > > the changes to Doc Text are sometimes split into several fields. We are not > sure if there's a character limit, or commas and newlines are used to split > the text. We propose to change the front-end rendering to display the Doc > Text history entries always in a single field. It is a character limit (255), but split back to the last comma or word. Bugzilla 4.4 (released May 19th UTC) should reconstitute the split fields back into one. Please open up a new bug if this is not the case. (reason for new bug: It is upstream code, so I want to track it separately from this issue) > 3. For emails, we propose to format changes to the Doc Text field the same > way BZ comments are formatted, see the example below. There is only one > additional feature request - to add a highlighted keyword about the change > to Doc Text: *added* or *updated* or *removed* Works for me. > Thank you for considering these ideas, NP. -- simon
Out of interest, the reconstitution of e-mails mentioned in comment 5 was only fixed in last weeks release (4.4-3.5). That was upstream būg 885646.
Question: For those that receive HTML e-mail, should the doc text autolinkify things (like bugs and URLs, as it does for comments), or should it use just plain text?
I never use HTML email, so don't really have an opinion on that.
(In reply to Daniel Berrange from comment #8) > I never use HTML email, so don't really have an opinion on that. Fair enough. In light of no objection, I am going to auto-linkify the new doc text. It can always be changed later if needed. -- simon
This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug. -- simon