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
|
<!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%09like%20--search-media&In-Reply-To=%3C2277719.nJcRoenmuF%40localhost%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="016721.html">
<LINK REL="Next" HREF="016723.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media</H1>
<B>AL13N</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%09like%20--search-media&In-Reply-To=%3C2277719.nJcRoenmuF%40localhost%3E"
TITLE="[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media">alien at rmail.be
</A><BR>
<I>Thu Jun 21 23:01:28 CEST 2012</I>
<P><UL>
<LI>Previous message: <A HREF="016721.html">[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media
</A></li>
<LI>Next message: <A HREF="016723.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#16722">[ date ]</a>
<a href="thread.html#16722">[ thread ]</a>
<a href="subject.html#16722">[ subject ]</a>
<a href="author.html#16722">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Op donderdag 21 juni 2012 22:21:52 schreef Sander Lepik:
><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 see...
however, as long as backports is installed, it could still be that due to an
update a new dependency from release is pulled, which could conflict (or not
work correctly) with some of the installed backports.
if we want to have supported both backports and updates, these cases should
still be tested. And if you want to support cherrypicking backports, the
possibilities are even bigger.
It seems to me that people don't really see what kind of QA resources
backports will need if all this need to be supported. This is completely
irrelevant to this solution however. whatever solution we pick for bug 2317
(A, B, or even doing nothing), it seems you think this solution has any effect
on QA resources, but it doesn't, it's only enabling backports that does it.
Let me give you an overview on options for the amount of support in backports
and it's impact on QA (also with example) for only 1 release:
(package X has update A & backport B;
package Y has update C and backport D;
package Z has update E and backport F)
A. backports is fully supported + cherry-picking backports is also supported
(for only mga2)
for update validation of package X (let's call it update A2):
1. testing combination: A,C,E for arch i586
2. testing combination: A,D,E for arch i586
3. testing combination: A,C,F for arch i586
4. testing combination: A,D,F for arch i586
5. testing combination: A,C,E for arch x86_64
6. testing combination: A,D,E for arch x86_64
7. testing combination: A,C,F for arch x86_64
8. testing combination: A,D,F for arch x86_64
for backport validation of package X (let's call it backport B2):
1. testing combination: B,C,E for arch i586
2. testing combination: B,D,E for arch i586
3. testing combination: B,C,F for arch i586
4. testing combination: B,D,F for arch i586
5. testing combination: B,C,E for arch x86_64
6. testing combination: B,D,E for arch x86_64
7. testing combination: B,C,F for arch x86_64
8. testing combination: B,D,F for arch x86_64
Validations required: 2*2^(number of backported packages - 1)
==> this is completely impossible
B. backports is fully supported, but cherry-picking isn't
for update validation of package X (let's call it update A2):
1. testing combination: A,C,E for arch i586
2. testing combination: A,D,F for arch i586
3. testing combination: A,C,E for arch x86_64
4. testing combination: A,D,F for arch x86_64
for backport validation of package X (let's call it backport B2):
1. testing combination: B,C,E for arch i586
2. testing combination: B,D,F for arch i586
3. testing combination: B,C,E for arch x86_64
4. testing combination: B,D,F for arch x86_64
Validations required: 4 for each package
==> this is quadrupling the QA workload
B2. i thought perhaps that testing these on one arch would be ok:
for update validation of package X (let's call it update A2):
1. testing combination: A,C,E for arch i586
2. testing combination: A,D,F for arch x86_64
OR
1. testing combination: A,D,F for arch i586
2. testing combination: A,C,E for arch x86_64
for backport validation of package X (let's call it backport B2):
1. testing combination: B,C,E for arch i586
2. testing combination: B,D,F for arch x86_64
OR
1. testing combination: B,D,F for arch i586
2. testing combination: B,C,E for arch x86_64
Validations required: 2 for each package
=> this could be doable by QA, even though it's perhaps not completely tested
C. perhaps backports being semi-supported
for update validation of package X (let's call it update A2):
1. testing combination: A,C,E for arch i586
2. testing combination: A,C,E for arch x86_64
for backport validation of package X (let's call it backport B2):
1. testing combination: B,C,E for arch i586
2. testing combination: B,C,E for arch x86_64
Validations required: 2 for each package
=> this could be doable by QA, but even though a package might work, it's
possible that an update (or backport), might not be cleanly installable and
give errors.
D. not supporting backports
for update validation of package X (let's call it update A2):
1. testing combination: A,C,E for arch i586
2. testing combination: A,C,E for arch x86_64
for backport validation of package X (let's call it backport B2):
No testing
Validations required: 2 for each update
=> this is how it is now
--------------------------------------------------
I would implore all of you to look at this above and try to understand.
(of course, you can tell me if i'm wrong here)
It seems to me that all of you had thought that C was good enough validation
(except for tv, i guess he saw this from the beginning and figured D would be
best or even E, no backports at all).
I'm was thinking that if C was good enough for you, then perhaps B2 would also
be good, as i think it doesn't give any extra load on QA.
IMPORTANT: Again, i'm stating that this does NOT matter whatever solution for
bug 2317 is chosen.
even my preferred solution on bug 2317 ONLY has more testing requirement for
the backport packager
Is this more clear?
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="016721.html">[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media
</A></li>
<LI>Next message: <A HREF="016723.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#16722">[ date ]</a>
<a href="thread.html#16722">[ thread ]</a>
<a href="subject.html#16722">[ subject ]</a>
<a href="author.html#16722">[ 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>
|
