On Fri, 11 Aug 2006 16:46:33 +0200 Jeroen Roovers <[EMAIL PROTECTED]> wrote:
> I explained from the outset that this change pertains to stabilisation > bugs. If you are not an arch dev, then why are you taking the opposite > side in a discussion of stabilisation bugs which by their very nature > only pertain to arch devs? Well, first off you asked for comments; "RFC". If I have something to say, I'll say it, even if I'm not immediately affected. You don't have to agree, or even pay attention ;) That said, as I described in my previous email, my concern was that if it becomes policy to attach `emerge --info` instead of inline for stabilisation bugs, that policy might expand to all bugs which would have a negative impact for me. However if the rule is only for "pass" `emerge --info` data then I don't object. > > 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. > > If it fails, the AT should open a separate bug and make the > stabilisation bug depend on it. Good point. > You said so yourself: > > "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." > > I absolutely agree with this. I assume now that you agree with me that > debugging info, including `emerge info`, should *never* be inlined in, > or even attached to, stabilisation bugs. Yes. -- Kevin F. Quinn
signature.asc
Description: PGP signature
