On Fri, 11 Aug 2006 13:40:23 +0200 Jeroen Roovers <[EMAIL PROTECTED]> wrote:
> 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. "Personally" is critical. Part of my point was that whatever way it's done, it will be better for some and worse for others. In other words, what is "better" is subjective. In order to decide to change how things are currently done, you need to show that it is better for a majority of the people affected. > 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 ok; that makes better sense. > > 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. Doesn't make the slightest difference to the burden on bugzilla, whether they're inline or attachments. Whether it's a burden on arch devs or not, you'd have to poll. If you do go this route, I suggest the attachment title be "PASS (emerge info)" or "FAIL (emerge info)"; easier to parse the attachment list. Also allows you to process email by just the subject header. > > 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. Well, I do think the report of the configuration the AT had at the time of the test should be held as close as possible to the place where it has relevance. As far as this point is concerned, having it as an attachment is fine. Having it posted on some website somewhere else as others have suggested is a bad idea, I think. > > 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. I don't understand how you're getting many pages in one email - surely each report by an AT is a separate comment and hence a separate email, looking like: ---- From: Mr Test Subject: Stabilisation of <CPV> Works Great!!!1omg emerge info: <40 lines> ---- and that's all. If it's of no interest to you, surely you just use "delete and next" rather than "mark read and next", whatever they are in your email reader. > > 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. I'll take "you" to mean "arch team members of arches with ATs" (rubbish language, English). I don't have a problem as things stand now. I might have a problem if all emerge info ends up in attachments (not just for stabilisation bugs). To be honest, what goes on for stabilisation bugs isn't of any direct concern to me as I don't involve myself in stabilisation, but if you change the rule there it's likely to be the rule across all of bugzilla and then it does concern me. > 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. Another idea is for ATs to attach emerge info if the package passes for them, but in-line it if it fails. If the package fails on one arch for a given set of USE/FEATURES, other arches may well be interested to check if the failure also affects them. -- Kevin F. Quinn
signature.asc
Description: PGP signature
