On Fri, 11 Aug 2006 12:52:30 +0200 "Kevin F. Quinn" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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@gentoo.org mailing list
