Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Kevin F. Quinn]

On Fri, 11 Aug 2006 00:51:56 +0200
Jeroen Roovers <jer@g.o> wrote:

> On Thu, 10 Aug 2006 23:58:46 +0200
> "Kevin F. Quinn" <kevquinn@g.o> 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