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