1 |
On Fri, 11 Aug 2006 13:40:23 +0200 |
2 |
Jeroen Roovers <jer@g.o> wrote: |
3 |
|
4 |
> On Fri, 11 Aug 2006 12:52:30 +0200 |
5 |
> "Kevin F. Quinn" <kevquinn@g.o> wrote: |
6 |
> |
7 |
> > In general it depends what you're doing. Personally I find inline |
8 |
> > emerge --info quicker to process, as I tend to do that by scrolling |
9 |
> > up and down a bug when trying to determine what triggers a bug. |
10 |
> > However that's for "normal" bugs - I don't spend much time on |
11 |
> > stabilisation bugs. |
12 |
> |
13 |
> "Personally" is meaningless in this context. |
14 |
|
15 |
"Personally" is critical. Part of my point was that whatever way it's |
16 |
done, it will be better for some and worse for others. In other words, |
17 |
what is "better" is subjective. In order to decide to change how |
18 |
things are currently done, you need to show that it is better for a |
19 |
majority of the people affected. |
20 |
|
21 |
> The inline `emerge info` |
22 |
> is quicker to process for you, not for other-arch devs out there. For |
23 |
> them the info is useless. Stabilisation bugs in this context are |
24 |
> bugs CC'd to many arch aliases (see below for a possible solution). |
25 |
> |
26 |
> > > you have to wade through all the AT spam to find out what is being |
27 |
> > > changed over time. It's best to have it in attachments, I think. |
28 |
> > > |
29 |
> > > Besides, you're wrong. ATs can add comments to attachments |
30 |
> > > informing their arch devs of success or failure, and name the |
31 |
> > > `emerge info` attachment properly so everybody knows what the |
32 |
> > > attachment actually is (and when to ignore it). |
33 |
> > |
34 |
> > In what way am I wrong? I never said AT's can't add comments. |
35 |
> |
36 |
> ATs can inform you whether something works in the comment to an |
37 |
> attachment, which, unlike the attachment, will end up in my mailbox. I |
38 |
> have no problems with short comments like: |
39 |
> |
40 |
> |
41 |
> ------- Comment #5 from jer@g.o 2006-08-01 02:47 PST ------- |
42 |
> Created an attachment (id=93193) |
43 |
> --> (http://bugs.gentoo.org/attachment.cgi?id=1&action=view) |
44 |
> emerge info |
45 |
> |
46 |
> Works Great!!!1omg |
47 |
|
48 |
ok; that makes better sense. |
49 |
|
50 |
> > Effectively what you're saying is transcribe the emerge info into |
51 |
> > the attachment name and attachment comment - which effectively |
52 |
> > makes it in-line again. |
53 |
> |
54 |
> No, I meant put the `emerge info` in the attachment, describe the |
55 |
> attachment properly ("emerge info" would do) and comment on the |
56 |
> attachment submission with a statement pertaining to the success or |
57 |
> failure of the test run. This can all be achieved in a single submit |
58 |
> and it doesn't burden arch devs and bugzilla with lengthy comments. |
59 |
|
60 |
Doesn't make the slightest difference to the burden on bugzilla, |
61 |
whether they're inline or attachments. |
62 |
|
63 |
Whether it's a burden on arch devs or not, you'd have to poll. |
64 |
|
65 |
If you do go this route, I suggest the attachment title be "PASS |
66 |
(emerge info)" or "FAIL (emerge info)"; easier to parse the attachment |
67 |
list. Also allows you to process email by just the subject header. |
68 |
|
69 |
> > Rule 1 in problem reporting - report your exact configuration and |
70 |
> > exactly what you see, in the first instance, do not attempt to |
71 |
> > interpret until you have that data recorded. |
72 |
> |
73 |
> Could you consider having ATs report the exact configuration |
74 |
> elsewhere? In normal bugs, encouraging users to post their emerge info |
75 |
> is a good thing. In stabilisation bugs, with well-instructed ATs |
76 |
> posting comments, there's no need to do all that. |
77 |
|
78 |
Well, I do think the report of the configuration the AT had at the time |
79 |
of the test should be held as close as possible to the place where it |
80 |
has relevance. As far as this point is concerned, having it as an |
81 |
attachment is fine. Having it posted on some website somewhere else as |
82 |
others have suggested is a bad idea, I think. |
83 |
|
84 |
> > Not sure I understand. Stabilisation bugs shouldn't be doing |
85 |
> > problem resolution; if a bug is found during stabilisation testing |
86 |
> > it should be raised as a normal bug and set as a dependency of the |
87 |
> > stabilisation bug. If people are using stabilisation bugs for |
88 |
> > development/bug fixing then they should stop doing so. |
89 |
> |
90 |
> N/A |
91 |
> |
92 |
> Stabilisation bugs should be short and simple. If the stabilisation |
93 |
> target changes half way through (a revision bump perhaps, which |
94 |
> happens quite often, or an extra dep, which happens quite often as |
95 |
> well), arch devs need to be able to find that information quickly. |
96 |
> |
97 |
> > Well, it adds around 40 lines - I don't see that as a problem. |
98 |
> > It's a good idea if the emerge info output is placed after whatever |
99 |
> > comment is being made, so that if you don't care about it you can |
100 |
> > just skip to the next message. |
101 |
> |
102 |
> Erm. It is a problem - I've explained why. It adds bloat and it clogs |
103 |
> many arch devs' mailboxen with tons of useless info. Merrily skipping |
104 |
> past it is impossible when a bug spans 5 instead of 2 pages because |
105 |
> of 3 AT comments, interspersed with possibly useful comments. I guess |
106 |
> you would feel the same way if I started inlining `emerge info` for |
107 |
> all my HPPA systems. You'd have to parse each one of them just to |
108 |
> find your own ATs' `emerge info` among mine. |
109 |
|
110 |
I don't understand how you're getting many pages in one email - surely |
111 |
each report by an AT is a separate comment and hence a separate |
112 |
email, looking like: |
113 |
|
114 |
---- |
115 |
From: Mr Test |
116 |
Subject: Stabilisation of <CPV> |
117 |
|
118 |
Works Great!!!1omg |
119 |
|
120 |
emerge info: |
121 |
<40 lines> |
122 |
---- |
123 |
|
124 |
and that's all. If it's of no interest to you, surely you just use |
125 |
"delete and next" rather than "mark read and next", whatever they are |
126 |
in your email reader. |
127 |
|
128 |
> > Stabilisation bugs by their very nature are temporary - they are |
129 |
> > active for the time it takes to decide a package can be marked |
130 |
> > stable. Once the package version is marked stable, the bug should |
131 |
> > be closed. I don't see what the communication problem is. |
132 |
> |
133 |
> Your communication problem used to be that you want the AT's info |
134 |
> ready to use. Your solution was to have ATs inline `emerge info` in |
135 |
> bug comments. This solution benefits only you, not other arches's |
136 |
> devs, and in fact, it annoys them. Please find a better solution. |
137 |
|
138 |
I'll take "you" to mean "arch team members of arches with ATs" (rubbish |
139 |
language, English). I don't have a problem as things stand now. I |
140 |
might have a problem if all emerge info ends up in attachments (not |
141 |
just for stabilisation bugs). To be honest, what goes on for |
142 |
stabilisation bugs isn't of any direct concern to me as I don't involve |
143 |
myself in stabilisation, but if you change the rule there it's likely |
144 |
to be the rule across all of bugzilla and then it does concern me. |
145 |
|
146 |
> One solution might be to open your own AT bug, make the stabilisation |
147 |
> bug depend on it, and use the AT bug to have ATs post their `emerge |
148 |
> info`. Then, when testing and stabilisation is finished for your arch, |
149 |
> close the AT bug and remove your alias from the stabilisation bug's CC |
150 |
> list. I for one could live with this solution to the problem, which I |
151 |
> hope you understand by now. |
152 |
|
153 |
Another idea is for ATs to attach emerge info if the package passes for |
154 |
them, but in-line it if it fails. If the package fails on one arch for |
155 |
a given set of USE/FEATURES, other arches may well be interested to |
156 |
check if the failure also affects them. |
157 |
|
158 |
-- |
159 |
Kevin F. Quinn |