1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] bug 2317 revisited: --update option should behave like --search-media
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20bug%202317%20revisited%3A%20--update%20option%20should%20behave%0A%20like%20--search-media&In-Reply-To=%3C4FE44484.1080001%40gmail.com%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="016752.html">
<LINK REL="Next" HREF="016743.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media</H1>
<B>Claire Robinson</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20bug%202317%20revisited%3A%20--update%20option%20should%20behave%0A%20like%20--search-media&In-Reply-To=%3C4FE44484.1080001%40gmail.com%3E"
TITLE="[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media">eeeemail at gmail.com
</A><BR>
<I>Fri Jun 22 12:10:12 CEST 2012</I>
<P><UL>
<LI>Previous message: <A HREF="016752.html">[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media
</A></li>
<LI>Next message: <A HREF="016743.html">[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#16738">[ date ]</a>
<a href="thread.html#16738">[ thread ]</a>
<a href="subject.html#16738">[ subject ]</a>
<a href="author.html#16738">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>On 21/06/12 22:01, AL13N wrote:
><i> Op donderdag 21 juni 2012 22:21:52 schreef Sander Lepik:
</I>>><i> On Jun 21, 2012 9:10 PM, "AL13N"<<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">alien at rmail.be</A>>
</I>>><i>
</I>>>><i> so, there's 2 options:
</I>>>><i>
</I>>>><i> - testing i586 with backports enabled
</I>>>><i> - testing x86_64 without backports enabled
</I>>>><i>
</I>>>><i> this is still 2 tests, and this is sufficient.
</I>>><i>
</I>>><i> Are you serious?
</I>>><i> I've seen bugs were i586 and x86_64 doesn't work quite the same. Every arch
</I>>><i> + repo must be tested separately (be it tainted or release, i'm still not
</I>>><i> mixing backports with updates ... until you promise to do all the testing
</I>>><i> here and not bother QA;)).
</I>><i>
</I>><i> I see...
</I>><i>
</I>><i> however, as long as backports is installed, it could still be that due to an
</I>><i> update a new dependency from release is pulled, which could conflict (or not
</I>><i> work correctly) with some of the installed backports.
</I>><i>
</I>><i> if we want to have supported both backports and updates, these cases should
</I>><i> still be tested. And if you want to support cherrypicking backports, the
</I>><i> possibilities are even bigger.
</I>><i>
</I>><i> It seems to me that people don't really see what kind of QA resources
</I>><i> backports will need if all this need to be supported. This is completely
</I>><i> irrelevant to this solution however. whatever solution we pick for bug 2317
</I>><i> (A, B, or even doing nothing), it seems you think this solution has any effect
</I>><i> on QA resources, but it doesn't, it's only enabling backports that does it.
</I>><i>
</I>><i> Let me give you an overview on options for the amount of support in backports
</I>><i> and it's impact on QA (also with example) for only 1 release:
</I>><i>
</I>><i> (package X has update A& backport B;
</I>><i> package Y has update C and backport D;
</I>><i> package Z has update E and backport F)
</I>><i>
</I>><i>
</I>><i> A. backports is fully supported + cherry-picking backports is also supported
</I>><i> (for only mga2)
</I>><i>
</I>><i> for update validation of package X (let's call it update A2):
</I>><i> 1. testing combination: A,C,E for arch i586
</I>><i> 2. testing combination: A,D,E for arch i586
</I>><i> 3. testing combination: A,C,F for arch i586
</I>><i> 4. testing combination: A,D,F for arch i586
</I>><i> 5. testing combination: A,C,E for arch x86_64
</I>><i> 6. testing combination: A,D,E for arch x86_64
</I>><i> 7. testing combination: A,C,F for arch x86_64
</I>><i> 8. testing combination: A,D,F for arch x86_64
</I>><i>
</I>><i> for backport validation of package X (let's call it backport B2):
</I>><i> 1. testing combination: B,C,E for arch i586
</I>><i> 2. testing combination: B,D,E for arch i586
</I>><i> 3. testing combination: B,C,F for arch i586
</I>><i> 4. testing combination: B,D,F for arch i586
</I>><i> 5. testing combination: B,C,E for arch x86_64
</I>><i> 6. testing combination: B,D,E for arch x86_64
</I>><i> 7. testing combination: B,C,F for arch x86_64
</I>><i> 8. testing combination: B,D,F for arch x86_64
</I>><i>
</I>><i> Validations required: 2*2^(number of backported packages - 1)
</I>><i> ==> this is completely impossible
</I>><i>
</I>><i> B. backports is fully supported, but cherry-picking isn't
</I>><i>
</I>><i> for update validation of package X (let's call it update A2):
</I>><i> 1. testing combination: A,C,E for arch i586
</I>><i> 2. testing combination: A,D,F for arch i586
</I>><i> 3. testing combination: A,C,E for arch x86_64
</I>><i> 4. testing combination: A,D,F for arch x86_64
</I>><i>
</I>><i> for backport validation of package X (let's call it backport B2):
</I>><i> 1. testing combination: B,C,E for arch i586
</I>><i> 2. testing combination: B,D,F for arch i586
</I>><i> 3. testing combination: B,C,E for arch x86_64
</I>><i> 4. testing combination: B,D,F for arch x86_64
</I>><i>
</I>><i> Validations required: 4 for each package
</I>><i> ==> this is quadrupling the QA workload
</I>><i>
</I>><i> B2. i thought perhaps that testing these on one arch would be ok:
</I>><i>
</I>><i> for update validation of package X (let's call it update A2):
</I>><i> 1. testing combination: A,C,E for arch i586
</I>><i> 2. testing combination: A,D,F for arch x86_64
</I>><i>
</I>><i> OR
</I>><i>
</I>><i> 1. testing combination: A,D,F for arch i586
</I>><i> 2. testing combination: A,C,E for arch x86_64
</I>><i>
</I>><i> for backport validation of package X (let's call it backport B2):
</I>><i> 1. testing combination: B,C,E for arch i586
</I>><i> 2. testing combination: B,D,F for arch x86_64
</I>><i>
</I>><i> OR
</I>><i>
</I>><i> 1. testing combination: B,D,F for arch i586
</I>><i> 2. testing combination: B,C,E for arch x86_64
</I>><i>
</I>><i> Validations required: 2 for each package
</I>><i> => this could be doable by QA, even though it's perhaps not completely tested
</I>><i>
</I>><i> C. perhaps backports being semi-supported
</I>><i>
</I>><i> for update validation of package X (let's call it update A2):
</I>><i> 1. testing combination: A,C,E for arch i586
</I>><i> 2. testing combination: A,C,E for arch x86_64
</I>><i>
</I>><i> for backport validation of package X (let's call it backport B2):
</I>><i> 1. testing combination: B,C,E for arch i586
</I>><i> 2. testing combination: B,C,E for arch x86_64
</I>><i>
</I>><i> Validations required: 2 for each package
</I>><i> => this could be doable by QA, but even though a package might work, it's
</I>><i> possible that an update (or backport), might not be cleanly installable and
</I>><i> give errors.
</I>><i>
</I>><i> D. not supporting backports
</I>><i>
</I>><i> for update validation of package X (let's call it update A2):
</I>><i> 1. testing combination: A,C,E for arch i586
</I>><i> 2. testing combination: A,C,E for arch x86_64
</I>><i>
</I>><i> for backport validation of package X (let's call it backport B2):
</I>><i> No testing
</I>><i>
</I>><i> Validations required: 2 for each update
</I>><i> => this is how it is now
</I>><i>
</I>><i> --------------------------------------------------
</I>><i> I would implore all of you to look at this above and try to understand.
</I>><i>
</I>><i> (of course, you can tell me if i'm wrong here)
</I>><i>
</I>><i>
</I>><i> It seems to me that all of you had thought that C was good enough validation
</I>><i> (except for tv, i guess he saw this from the beginning and figured D would be
</I>><i> best or even E, no backports at all).
</I>><i>
</I>><i> I'm was thinking that if C was good enough for you, then perhaps B2 would also
</I>><i> be good, as i think it doesn't give any extra load on QA.
</I>><i>
</I>><i>
</I>><i> IMPORTANT: Again, i'm stating that this does NOT matter whatever solution for
</I>><i> bug 2317 is chosen.
</I>><i>
</I>><i> even my preferred solution on bug 2317 ONLY has more testing requirement for
</I>><i> the backport packager
</I>><i>
</I>><i>
</I>><i> Is this more clear?
</I>
All this assumes that backport media will be treated as a normal update
media. That is certainly not my impression. My impression of backports
are being able to install a new blender for example, not having a system
where backports are just another update media and replace everything
available. The QA task for that scenario would be ridiculously huge. If
you want to have backports which go any further than backports testing
then you seriously need to rethink this idea.
I don't think you understand quite how short handed we are in QA. For
the life of Mageia 1 it was mainly just two people. This bug is a major
bug for QA and has been since it was first discovered almost a year ago.
It adds complexity and extra workload to an already severely overloaded
team.
We have a few (very few) new people since Mageia 2 was released who are
beginning to help out, understand the process and how to find ways to
test things. Thankyou all, you know who you are. The complexity of
working around this bug is something they shouldn't have to learn. The
extra workload involved in working around this bug is something we can't
continue with, even in our current state with no backport medias. I
spent most of yesterday on it for example instead of testing updates.
Validating updates is now taking twice as long because there is twice as
much testing involved for two releases - plus the extra time spent
working around bug 2317 for each release. Yesterday we even found its
effects are different for some rpm's on i586 than they are on x86_64
(see p11-kit bug 6502).
Anything which, at this stage, slows this process further will lead to
updates being further and further delayed. That is a situation nobody
wants to see, and personally I'd like to be able to take a day off now
and again too. I'm sure others feel the same.
The aim of fixing this bug is to reduce the complexity and extra
workload of working around it for QA. This assumption and solution
actually has the opposite effect, dramatically increasing the complexity
and workload. As I've explained, that is simply not possible if we want
to release timely updates.
I hope this makes the situation clearer. There is a workable solution
but I'm afraid it isn't this one, for the reasons given above.
Thanks
Claire
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="016752.html">[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media
</A></li>
<LI>Next message: <A HREF="016743.html">[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#16738">[ date ]</a>
<a href="thread.html#16738">[ thread ]</a>
<a href="subject.html#16738">[ subject ]</a>
<a href="author.html#16738">[ author ]</a>
</LI>
</UL>
<hr>
<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev
mailing list</a><br>
</body></html>
|
