diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2012-June/016746.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-June/016746.html | 207 |
1 files changed, 207 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-June/016746.html b/zarb-ml/mageia-dev/2012-June/016746.html new file mode 100644 index 000000000..3156c8df7 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-June/016746.html @@ -0,0 +1,207 @@ +<!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=%3C4FE456DA.1040505%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="016761.html"> + <LINK REL="Next" HREF="016742.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media</H1> + <B>andre999</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=%3C4FE456DA.1040505%40laposte.net%3E" + TITLE="[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media">andre999mga at laposte.net + </A><BR> + <I>Fri Jun 22 13:28:26 CEST 2012</I> + <P><UL> + <LI>Previous message: <A HREF="016761.html">[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media +</A></li> + <LI>Next message: <A HREF="016742.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#16746">[ date ]</a> + <a href="thread.html#16746">[ thread ]</a> + <a href="subject.html#16746">[ subject ]</a> + <a href="author.html#16746">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>AL13N a écrit : +>><i> On 21/06/12 22:01, AL13N wrote: +</I>>><i> +</I>><i> [...] +</I>><i> +</I>>><i> All this assumes that backport media will be treated as a normal update +</I>>><i> media. That is certainly not my impression. My impression of backports +</I>>><i> are being able to install a new blender for example, not having a system +</I>>><i> where backports are just another update media and replace everything +</I>>><i> available. The QA task for that scenario would be ridiculously huge. If +</I>>><i> you want to have backports which go any further than backports testing +</I>>><i> then you seriously need to rethink this idea. +</I>>><i> +</I>><i> [...] +</I>><i> +</I>>><i> The aim of fixing this bug is to reduce the complexity and extra +</I>>><i> workload of working around it for QA. This assumption and solution +</I>>><i> actually has the opposite effect, dramatically increasing the complexity +</I>>><i> and workload. As I've explained, that is simply not possible if we want +</I>>><i> to release timely updates. +</I>>><i> +</I>>><i> I hope this makes the situation clearer. There is a workable solution +</I>>><i> but I'm afraid it isn't this one, for the reasons given above. +</I>>><i> +</I>><i> No offense, but i think it didn't make myself clear and as a result i +</I>><i> think you are not understanding this properly. +</I>><i> +</I>><i> my proposal is actually to make sure QA only needs to test twice for each +</I>><i> package (both updates and backports). +</I>><i> +</I>><i> "My impression of backports are being able to install a new blender for +</I>><i> example" +</I>><i> +</I>><i> this exact idea that you have, will make QA testing unworkable. let me try +</I>><i> to explain: +</I>><i> +</I>><i> suppose that only blender and firefox and gimp and java is backported. any +</I>><i> kind of combination would have to be tested to be able to support +</I>><i> backports: +</I>><i> - testing backports blender on a system without backports +</I>><i> - testing backports blender on a system with backports and only firefox +</I>><i> installed from backports +</I>><i> - testing backports blender on a system with backports and only gimp +</I>><i> installed from backports +</I>><i> - testing backports blender on a system with backports and only java +</I>><i> installed from backports +</I>><i> - testing backports blender on a system with backports and both firefox +</I>><i> and gimp installed from backports +</I>><i> - testing backports blender on a system with backports and both firefox +</I>><i> and java installed from backports +</I>><i> - testing backports blender on a system with backports and both gimp and +</I>><i> java installed from backports +</I>><i> - testing backports blender on a system with backports and firefox and +</I>><i> gimp and java installed from backports +</I>><i> +</I>><i> This for each arch: thus 16 tests. +</I>><i> +</I> +This analysis makes absolutely no sense. +All "cherry-picking" backports means is that a user can choose to +install only one or several backport packages, just as a user can +install only one or several optional release packages, or one or several +proposed updates. +Do you really think that QA tests release blender with/without firefox +installed, with/without gimp installed, etc ? Considering that there +are a lot more than 5 optional packages in a release, that would make an +incredible number of tests. + +><i> This amount of tests is a direct result of trying to support backports +</I>><i> when you can have any single backported package installed, that you want. +</I>><i> +</I>><i> you'd have to test this because in case of new dependencies, it could even +</I>><i> conflict during installation!!! +</I>><i> +</I>><i> and the biggest problem is that the same problem exists when having an +</I>><i> update that has a new dependency. Thus, the same tests should be done for +</I>><i> updates as well. +</I>><i> +</I>><i> all of this, just to support backports being cherry-picked. +</I>><i> +</I> +Just think what is meant by "cherry-picked". + +><i> I'd rather have unsupported backports. +</I>><i> +</I>><i> My proposal (B2) is a compromise that has only supporting backports if you +</I>><i> use it for everything, and has only 2 tests per package. THE SAME AS WE DO +</I>><i> NOW! +</I>><i> +</I> +Which is all that is ever needed. + +><i> to repeat: i'm trying to propose a solution that makes QA have NO INCREASE +</I>><i> of workload. +</I>><i> +</I> +It does increase the total workload, as each backport package has to be +tested in the release to which it applies. But only one test per +architecture. +Don't forget that backports will be leaf packages (or a set of related +packages on which nothing else is dependant), so they will be simpler to +test. + +><i> the only extra point, is that for validating: +</I>><i> +</I>><i> right now, you're asking if it's tested for both i586 and x86_64. +</I>><i> +</I>><i> for B2, this is still the same, except that i586 should have backports +</I>><i> disabled and x86_64 have backports enabled. +</I>><i> +</I>><i> I hope this is clearer now +</I>><i> +</I> +-- +André + +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="016761.html">[Mageia-dev] bug 2317 revisited: --update option should behave like --search-media +</A></li> + <LI>Next message: <A HREF="016742.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#16746">[ date ]</a> + <a href="thread.html#16746">[ thread ]</a> + <a href="subject.html#16746">[ subject ]</a> + <a href="author.html#16746">[ 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> |