diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2012-June/016722.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-June/016722.html | 245 |
1 files changed, 245 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-June/016722.html b/zarb-ml/mageia-dev/2012-June/016722.html new file mode 100644 index 000000000..9a1f050e9 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-June/016722.html @@ -0,0 +1,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> |