| 1 |
On Fri, 11 Aug 2006 16:46:33 +0200 |
| 2 |
Jeroen Roovers <jer@g.o> wrote: |
| 3 |
|
| 4 |
> I explained from the outset that this change pertains to stabilisation |
| 5 |
> bugs. If you are not an arch dev, then why are you taking the opposite |
| 6 |
> side in a discussion of stabilisation bugs which by their very nature |
| 7 |
> only pertain to arch devs? |
| 8 |
|
| 9 |
Well, first off you asked for comments; "RFC". If I have something to |
| 10 |
say, I'll say it, even if I'm not immediately affected. You don't have |
| 11 |
to agree, or even pay attention ;) That said, as I described in my |
| 12 |
previous email, my concern was that if it becomes policy to attach |
| 13 |
`emerge --info` instead of inline for stabilisation bugs, that policy |
| 14 |
might expand to all bugs which would have a negative impact for me. |
| 15 |
However if the rule is only for "pass" `emerge --info` data then I |
| 16 |
don't object. |
| 17 |
|
| 18 |
> > Another idea is for ATs to attach emerge info if the package passes |
| 19 |
> > for them, but in-line it if it fails. If the package fails on one |
| 20 |
> > arch for a given set of USE/FEATURES, other arches may well be |
| 21 |
> > interested to check if the failure also affects them. |
| 22 |
> |
| 23 |
> If it fails, the AT should open a separate bug and make the |
| 24 |
> stabilisation bug depend on it. |
| 25 |
|
| 26 |
Good point. |
| 27 |
|
| 28 |
> You said so yourself: |
| 29 |
> |
| 30 |
> "Stabilisation bugs shouldn't be doing problem resolution; if a bug is |
| 31 |
> found during stabilisation testing it should be raised as a normal bug |
| 32 |
> and set as a dependency of the stabilisation bug." |
| 33 |
> |
| 34 |
> I absolutely agree with this. I assume now that you agree with me that |
| 35 |
> debugging info, including `emerge info`, should *never* be inlined in, |
| 36 |
> or even attached to, stabilisation bugs. |
| 37 |
|
| 38 |
Yes. |
| 39 |
|
| 40 |
-- |
| 41 |
Kevin F. Quinn |
Archives