1 |
On Fri, 11 Aug 2006 15:25:11 +0200 |
2 |
"Kevin F. Quinn" <kevquinn@g.o> wrote: |
3 |
|
4 |
> In order to decide to change how things are currently done, you need |
5 |
> to show that it is better for a majority of the people affected. |
6 |
|
7 |
(N minus 1 of N arches) times (the number of arch devs minus the number |
8 |
of $ARCH devs) are affected. |
9 |
|
10 |
The difference in comfort versus annoyance is even greater when you |
11 |
consider that only one arch dev per AT-equipped arch is likely to look |
12 |
at it and make the stabilisation judgment and then take action. That's |
13 |
N -1 arch dev's comfort against N arch devs' annoyance[1]. |
14 |
|
15 |
> > No, I meant put the `emerge info` in the attachment, describe the |
16 |
> > attachment properly ("emerge info" would do) and comment on the |
17 |
> > attachment submission with a statement pertaining to the success or |
18 |
> > failure of the test run. This can all be achieved in a single submit |
19 |
> > and it doesn't burden arch devs and bugzilla with lengthy comments. |
20 |
> |
21 |
> Doesn't make the slightest difference to the burden on bugzilla, |
22 |
> whether they're inline or attachments. |
23 |
|
24 |
Note that I specifically said "with lengthy comments". |
25 |
|
26 |
> Whether it's a burden on arch devs or not, you'd have to poll. |
27 |
|
28 |
Mailing 2.4kB instead 5kB to many dozens of people sure constitutes a |
29 |
smaller burden on bugzilla and on dev.gentoo.org, wrt the |
30 |
attachment solution, and on all the arch devs to whom the information is |
31 |
useless. |
32 |
|
33 |
Alternatively, wrt the AT bug solution, mailing 5kB to $ARCH@g.o (arch |
34 |
devs and ATs for one arch) instead of mailing same to $ARCHES@g.o (all |
35 |
arch devs and ATs for all arches) makes a pretty big difference. |
36 |
|
37 |
> If you do go this route, I suggest the attachment title be "PASS |
38 |
> (emerge info)" or "FAIL (emerge info)"; easier to parse the attachment |
39 |
> list. Also allows you to process email by just the subject header. |
40 |
|
41 |
Suits me. |
42 |
|
43 |
> Well, I do think the report of the configuration the AT had at the |
44 |
> time of the test should be held as close as possible to the place |
45 |
> where it has relevance. As far as this point is concerned, having it |
46 |
> as an attachment is fine. Having it posted on some website somewhere |
47 |
> else as others have suggested is a bad idea, I think. |
48 |
|
49 |
Back to the attachments solution, then. |
50 |
|
51 |
> I don't understand how you're getting many pages in one email - surely |
52 |
> each report by an AT is a separate comment and hence a separate |
53 |
> email, looking like: |
54 |
> |
55 |
> ---- |
56 |
> From: Mr Test |
57 |
> Subject: Stabilisation of <CPV> |
58 |
> |
59 |
> Works Great!!!1omg |
60 |
> |
61 |
> emerge info: |
62 |
> <40 lines> |
63 |
> ---- |
64 |
> |
65 |
> and that's all. If it's of no interest to you, surely you just use |
66 |
> "delete and next" rather than "mark read and next", whatever they are |
67 |
> in your email reader. |
68 |
|
69 |
It's 40 lines too many. That's the problem, both on bugs.g.o and in my |
70 |
mailbox. |
71 |
|
72 |
> To be honest, what goes on for stabilisation bugs isn't of any direct |
73 |
> concern to me as I don't involve myself in stabilisation, but if you |
74 |
> change the rule there it's likely to be the rule across all of |
75 |
> bugzilla and then it does concern me. |
76 |
|
77 |
I explained from the outset that this change pertains to stabilisation |
78 |
bugs. If you are not an arch dev, then why are you taking the opposite |
79 |
side in a discussion of stabilisation bugs which by their very nature |
80 |
only pertain to arch devs? I sure hope you didn't just knee jerk when |
81 |
you read the message subject. Here is the original first sentence of |
82 |
the first message in this thread: |
83 |
|
84 |
I propose the `emerge --info` included in arch testers' comments on |
85 |
stabilisation bugs should rather be posted as attachments. |
86 |
|
87 |
Any more questions? :-/ |
88 |
|
89 |
> Another idea is for ATs to attach emerge info if the package passes |
90 |
> for them, but in-line it if it fails. If the package fails on one |
91 |
> arch for a given set of USE/FEATURES, other arches may well be |
92 |
> interested to check if the failure also affects them. |
93 |
|
94 |
If it fails, the AT should open a separate bug and make the |
95 |
stabilisation bug depend on it. You said so yourself: |
96 |
|
97 |
"Stabilisation bugs shouldn't be doing problem resolution; if a bug is |
98 |
found during stabilisation testing it should be raised as a normal bug |
99 |
and set as a dependency of the stabilisation bug." |
100 |
|
101 |
I absolutely agree with this. I assume now that you agree with me that |
102 |
debugging info, including `emerge info`, should *never* be inlined in, |
103 |
or even attached to, stabilisation bugs. |
104 |
|
105 |
|
106 |
Kind regards, |
107 |
JeR |
108 |
|
109 |
|
110 |
[1] Note that I am aware that not all other-arch devs might experience |
111 |
inline `emerge info` for other arches as annoying. |
112 |
-- |
113 |
gentoo-dev@g.o mailing list |