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

[Jeroen Roovers]

On Fri, 11 Aug 2006 12:52:30 +0200
"Kevin F. Quinn" <kevquinn@g.o> wrote:

> 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.

"Personally" is meaningless in this context. The inline `emerge info`
is quicker to process for you, not for other-arch devs out there. For
them the info is useless. Stabilisation bugs in this context are bugs
CC'd to many arch aliases (see below for a possible solution).

> > 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.

ATs can inform you whether something works in the comment to an
attachment, which, unlike the attachment, will end up in my mailbox. I
have no problems with short comments like:


  ------- Comment #5 from jer@g.o  2006-08-01 02:47 PST -------
  Created an attachment (id=93193)
   --> (http://bugs.gentoo.org/attachment.cgi?id=1&action=view)
  emerge info

  Works Great!!!1omg


> Effectively what you're saying is transcribe the emerge info into the
> attachment name and attachment comment - which effectively makes it
> in-line again.

No, I meant put the `emerge info` in the attachment, describe the
attachment properly ("emerge info" would do) and comment on the
attachment submission with a statement pertaining to the success or
failure of the test run. This can all be achieved in a single submit
and it doesn't burden arch devs and bugzilla with lengthy comments.

> 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.

Could you consider having ATs report the exact configuration
elsewhere? In normal bugs, encouraging users to post their emerge info
is a good thing. In stabilisation bugs, with well-instructed ATs
posting comments, there's no need to do all that.

> 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.

N/A

Stabilisation bugs should be short and simple. If the stabilisation
target changes half way through (a revision bump perhaps, which
happens quite often, or an extra dep, which happens quite often as
well), arch devs need to be able to find that information quickly.

> 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.

Erm. It is a problem - I've explained why. It adds bloat and it clogs
many arch devs' mailboxen with tons of useless info. Merrily skipping
past it is impossible when a bug spans 5 instead of 2 pages because
of 3 AT comments, interspersed with possibly useful comments. I guess
you would feel the same way if I started inlining `emerge info` for all
my HPPA systems. You'd have to parse each one of them just to find your
own ATs' `emerge info` among mine.

> 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.

Your communication problem used to be that you want the AT's info
ready to use. Your solution was to have ATs inline `emerge info` in bug
comments. This solution benefits only you, not other arches's devs, and
in fact, it annoys them. Please find a better solution.

One solution might be to open your own AT bug, make the stabilisation
bug depend on it, and use the AT bug to have ATs post their `emerge
info`. Then, when testing and stabilisation is finished for your arch,
close the AT bug and remove your alias from the stabilisation bug's CC
list. I for one could live with this solution to the problem, which I
hope you understand by now.


Kind regards,
     JeR
-- 
gentoo-dev@g.o mailing list