[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media

[AL13N]

Op donderdag 21 juni 2012 22:21:52 schreef Sander Lepik:
> On Jun 21, 2012 9:10 PM, "AL13N" <alien at 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?