Op donderdag 21 juni 2012 22:21:52 schreef Sander Lepik:
On Jun 21, 2012 9:10 PM, "AL13N"<al...@rmail.be>
so, there's 2 options:
- testing i586 with backports enabled
- testing x86_64 without backports enabled
this is still 2 tests, and this is sufficient.
Are you serious?
I've seen bugs were i586 and x86_64 doesn't work quite the same. Every arch
+ repo must be tested separately (be it tainted or release, i'm still not
mixing backports with updates ... until you promise to do all the testing
here and not bother QA;)).
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?
