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

Fri Jun 22 12:42:46 CEST 2012

> On 21/06/12 22:01, AL13N wrote:
+[...]
+> 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.
+[...]
+> 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.
+
+No offense, but i think it didn't make myself clear and as a result i
+think you are not understanding this properly.
+
+my proposal is actually to make sure QA only needs to test twice for each
+package (both updates and backports).
+
+"My impression of backports are being able to install a new blender for
+example"
+
+this exact idea that you have, will make QA testing unworkable. let me try
+to explain:
+
+suppose that only blender and firefox and gimp and java is backported. any
+kind of combination would have to be tested to be able to support
+backports:
+- testing backports blender on a system without backports
+- testing backports blender on a system with backports and only firefox
+installed from backports
+- testing backports blender on a system with backports and only gimp
+installed from backports
+- testing backports blender on a system with backports and only java
+installed from backports
+- testing backports blender on a system with backports and both firefox
+and gimp installed from backports
+- testing backports blender on a system with backports and both firefox
+and java installed from backports
+- testing backports blender on a system with backports and both gimp and
+java installed from backports
+- testing backports blender on a system with backports and firefox and
+gimp and java installed from backports
+
+This for each arch: thus 16 tests.
+
+This amount of tests is a direct result of trying to support backports
+when you can have any single backported package installed, that you want.
+
+you'd have to test this because in case of new dependencies, it could even
+conflict during installation!!!
+
+and the biggest problem is that the same problem exists when having an
+update that has a new dependency. Thus, the same tests should be done for
+updates as well.
+
+all of this, just to support backports being cherry-picked.
+
+I'd rather have unsupported backports.
+
+My proposal (B2) is a compromise that has only supporting backports if you
+use it for everything, and has only 2 tests per package. THE SAME AS WE DO
+NOW!
+
+to repeat: i'm trying to propose a solution that makes QA have NO INCREASE
+of workload.
+
+the only extra point, is that for validating:
+
+right now, you're asking if it's tested for both i586 and x86_64.
+
+for B2, this is still the same, except that i586 should have backports
+disabled and x86_64 have backports enabled.
+
+I hope this is clearer now
+