On Fri, 11 Aug 2006 00:51:56 +0200 Jeroen Roovers <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Aug 2006 23:58:46 +0200 > "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: > > > The problem with attachments is that processing the report takes > > longer > > - you have to go to the web to read the attachment to find out what > > config worked (or failed, if that was the case). It's best to have > > it in-line, I think. > > The problem with inlining is that processing the info takes longer - In general it depends what you're doing. Personally I find inline emerge --info quicker to process, as I tend to do that by scrolling up and down a bug when trying to determine what triggers a bug. However that's for "normal" bugs - I don't spend much time on stabilisation bugs. > you have to wade through all the AT spam to find out what is being > changed over time. It's best to have it in attachments, I think. > > Besides, you're wrong. ATs can add comments to attachments informing > their arch devs of success or failure, and name the `emerge info` > attachment properly so everybody knows what the attachment actually is > (and when to ignore it). In what way am I wrong? I never said AT's can't add comments. Effectively what you're saying is transcribe the emerge info into the attachment name and attachment comment - which effectively makes it in-line again. Obviously only a tiny part of that can actually be put in the attachment name, and there's little point to putting stuff in the attachment comment unless it's highly redacted - how is the AT going to decide what information is significant? Rule 1 in problem reporting - report your exact configuration and exactly what you see, in the first instance, do not attempt to interpret until you have that data recorded. > > If you're not interested in the AT emerge --info data, why are you > > watching the stabilisation bug? > > Because as an arch dev not on an AT-equipped arch, I still need to > find the interesting-not-your-arch-info between all the > your-arch-cruft. Not sure I understand. Stabilisation bugs shouldn't be doing problem resolution; if a bug is found during stabilisation testing it should be raised as a normal bug and set as a dependency of the stabilisation bug. If people are using stabilisation bugs for development/bug fixing then they should stop doing so. > All these `emerge info` comments are completely irrelevant to every > arch dev for 14-ish out of 15-ish arches. Arch devs blessed with ATs' > preparations have their work cut out for them, it seems, having all > that info in their mailbox, while non-AT arches have to fork through > all the spam, both in their mailboxes and on bugs.g.o, to get to the > good bits (ouch, sparc beat us again, must stabilise before mips!). > > Inlining emerge info in comments bloats the e-mail message to roughly > 2.5 times the normal size. Well, it adds around 40 lines - I don't see that as a problem. It's a good idea if the emerge info output is placed after whatever comment is being made, so that if you don't care about it you can just skip to the next message. > I could have spoken out to get AT comments > banned altogether or to urge arches with AT teams to find a proper > technical solution to communicate outside of bugs.g.o. I think using > attachments instead of inlining is a pretty good temporary solution to > a communication problem that has for now been solved by making every > stabilisation bug report a dumping ground for a ton of information > that becomes obsolete within a few days. Stabilisation bugs by their very nature are temporary - they are active for the time it takes to decide a package can be marked stable. Once the package version is marked stable, the bug should be closed. I don't see what the communication problem is. -- Kevin F. Quinn
signature.asc
Description: PGP signature
