| 1 |
On Thu, 10 Aug 2006 23:58:46 +0200 |
| 2 |
"Kevin F. Quinn" <kevquinn@g.o> wrote: |
| 3 |
|
| 4 |
> The problem with attachments is that processing the report takes |
| 5 |
> longer |
| 6 |
> - you have to go to the web to read the attachment to find out what |
| 7 |
> config worked (or failed, if that was the case). It's best to have it |
| 8 |
> in-line, I think. |
| 9 |
|
| 10 |
The problem with inlining is that processing the info takes longer - |
| 11 |
you have to wade through all the AT spam to find out what is being |
| 12 |
changed over time. It's best to have it in attachments, I think. |
| 13 |
|
| 14 |
Besides, you're wrong. ATs can add comments to attachments informing |
| 15 |
their arch devs of success or failure, and name the `emerge info` |
| 16 |
attachment properly so everybody knows what the attachment actually is |
| 17 |
(and when to ignore it). |
| 18 |
|
| 19 |
> If you're not interested in the AT emerge --info data, why are you |
| 20 |
> watching the stabilisation bug? |
| 21 |
|
| 22 |
Because as an arch dev not on an AT-equipped arch, I still need to find |
| 23 |
the interesting-not-your-arch-info between all the your-arch-cruft. |
| 24 |
|
| 25 |
All these `emerge info` comments are completely irrelevant to every |
| 26 |
arch dev for 14-ish out of 15-ish arches. Arch devs blessed with ATs' |
| 27 |
preparations have their work cut out for them, it seems, having all |
| 28 |
that info in their mailbox, while non-AT arches have to fork through |
| 29 |
all the spam, both in their mailboxes and on bugs.g.o, to get to the |
| 30 |
good bits (ouch, sparc beat us again, must stabilise before mips!). |
| 31 |
|
| 32 |
Inlining emerge info in comments bloats the e-mail message to roughly |
| 33 |
2.5 times the normal size. I could have spoken out to get AT comments |
| 34 |
banned altogether or to urge arches with AT teams to find a proper |
| 35 |
technical solution to communicate outside of bugs.g.o. I think using |
| 36 |
attachments instead of inlining is a pretty good temporary solution to |
| 37 |
a communication problem that has for now been solved by making every |
| 38 |
stabilisation bug report a dumping ground for a ton of information that |
| 39 |
becomes obsolete within a few days. |
| 40 |
|
| 41 |
|
| 42 |
Kind regards, |
| 43 |
JeR |
| 44 |
-- |
| 45 |
gentoo-dev@g.o mailing list |
Archives