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

Fri Jun 22 13:28:26 CEST 2012

AL13N a écrit :
+>> 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 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.
+
+> 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.
+>    
+
+Just think what is meant by "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!
+>    
+
+Which is all that is ever needed.
+
+> to repeat: i'm trying to propose a solution that makes QA have NO INCREASE
+> of workload.
+>    
+
+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.
+
+> 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
+>    
+
+-- 
+André
+
+