From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2012-January/011283.html | 132 ++++++++++++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-January/011283.html (limited to 'zarb-ml/mageia-dev/2012-January/011283.html') diff --git a/zarb-ml/mageia-dev/2012-January/011283.html b/zarb-ml/mageia-dev/2012-January/011283.html new file mode 100644 index 000000000..313c0a588 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011283.html @@ -0,0 +1,132 @@ + + + + [Mageia-dev] please stop doing "bugs" for updating magia 1 + + + + + + + + + +

[Mageia-dev] please stop doing "bugs" for updating magia 1

+ andre999 + andre999mga at laposte.net +
+ Thu Jan 12 13:47:05 CET 2012 +

+
+ +
Buchan Milne a écrit :
+> On Wednesday, 11 January 2012 22:10:01 Juan Luis Baptiste wrote:
+>    
+>> On Wed, Jan 11, 2012 at 2:10 PM, Michael Scherer<misc at zarb.org>  wrote:
+>>      
+>>> Le mercredi 11 janvier 2012 à 11:24 -0500, Juan Luis Baptiste a écrit :
+>>>
+>>> So trusting and having bugs are totally unrelated. And if you doubt that
+>>> bugs appear, just see our bugzilla.
+>>> We trust upstream ( most of them ), and yet there is bugs.
+>>>        
+>> No, they're not totally unrelated when we don't have the man power to
+>> do through QA on every package, we need to trust on the packager (and
+>> upstream of course) that he did his best to test the new version
+>> without expecting him to have tested all the new features, Or do you
+>> expect that a QA member get a list of all the new features of a
+>> backport and start testing them one by one ? that's what I call
+>> unrealistic in practice.
+>>
+>>      
+>>>> If you think that all version backports should be tested in the same
+>>>> way as updates by QA, then all versions upgrades in cauldron should be
+>>>> tested by QA before pushing them to the BS right ?
+>>>>          
+>>> No, they should be tested before being put in the stable release. And
+>>> that's exactly what we do by freezing and testing before release.
+>>>        
+>> Of course but again, we can't test *all* the new features of *all* the
+>> programs that are going to a new release, we do our best for most of
+>> them. Critical components like installer, kernel, drak* tools, etc
+>> need more testing and that's where (our very small team) QA should
+>> spend their time after a freeze. The rest we have to do our best to
+>> test after each version update of a package.
+>>      
+> And this is IMHO why we should not necessarily enforce full QA on backports.
+>
+> It is ridiculous to enforce more testing on a package in backports, than most
+> likely was done for it while in cauldron before a release, especially
+> considering the user has a relatively easy mechanism for reverting to the
+> working package.
+>
+> If QA can state definitively that every package in a release is fully tested,
+> then I might agree.
+>
+> But, some of the reason to *have* backports is to allow users on stable
+> releases to test new versions that exist in cauldron.
+>
+> Regards,
+> Buchan
+>
+>    
++1
+If I remember correctly, our early discussions on backports proposed 
+that most of the responsibility for testing would be by those requesting 
+the backport in question, and the developer and/or maintainer.  So that 
+QA would give priority to regular updates.
+And that backports may have somewhat less testing, although we would try 
+to give the same level of testing as regular updates.
+The requirement to have them first in cauldron was at least partly 
+related to increasing the quality of backports.
+I agree that it is important to enable backports, to help ensure a 
+higher quality than will likely result with too much use of 3rd-party repos.
+
+Regards
+
+-- 
+André
+
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1