| 1 |
On Fri, 11 Aug 2006 04:56:18 +0000 (UTC) |
| 2 |
"Duncan" <1i5t5.duncan@×××.net> wrote: |
| 3 |
|
| 4 |
> Even back before it became the "in" thing, I was posting emerge |
| 5 |
> --info as attachments, because it simply fit the bill -- bugzy /says/ |
| 6 |
> to put long stuff as attachments. I never did quite understand why |
| 7 |
> all that admittedly often useful high-volume spew was tolerated in |
| 8 |
> the bug comments themselves. |
| 9 |
|
| 10 |
Personally I find it a lot easier to read a bug when the emerge --info |
| 11 |
data from people is inline. Frequently, the trigger for a bug becomes |
| 12 |
apparent when you compare the emerge --info of the various people who |
| 13 |
see a bug, and it's a moment's effort to scroll up and down the bug to |
| 14 |
compare data. This process takes longer if the info is in a bunch of |
| 15 |
attachments. |
| 16 |
|
| 17 |
[re. posting AT configs somewhere] |
| 18 |
> I like the idea above, tho. For ATs especially, having some place |
| 19 |
> where emerge --info could be posted just once, with a link to it |
| 20 |
> instead of the duplicated inline /or/ attachment, makes even more |
| 21 |
> sense. Presumably, where it's posted could have dated versions, too, |
| 22 |
> allowing for updated flags without invalidating the info pointed to |
| 23 |
> for older links. If variation off the norm was needed or used for an |
| 24 |
> individual package, that could be noted in the comments along with |
| 25 |
> the link to the standard info. |
| 26 |
|
| 27 |
I think the info changes frequently enough that it's easier, and more |
| 28 |
likely to be correct, if it's posted to the bug at the time the report |
| 29 |
is made. |
| 30 |
|
| 31 |
-- |
| 32 |
Kevin F. Quinn |
Archives