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-June/016768.html | 151 +++++++++++++++++++++++++++++++ 1 file changed, 151 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-June/016768.html (limited to 'zarb-ml/mageia-dev/2012-June/016768.html') diff --git a/zarb-ml/mageia-dev/2012-June/016768.html b/zarb-ml/mageia-dev/2012-June/016768.html new file mode 100644 index 000000000..1a7a37e12 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-June/016768.html @@ -0,0 +1,151 @@ + + + + [Mageia-dev] bug 2317 revisited: --update option should behave like --search-media + + + + + + + + + +

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

+ andre999 + andre999mga at laposte.net +
+ Sat Jun 23 01:39:58 CEST 2012 +

+
+ +
AL13N a écrit :
+> Op vrijdag 22 juni 2012 18:14:50 schreef David W. Hodgins:
+>    
+>> On Fri, 22 Jun 2012 14:11:58 -0400, AL13N<alien at rmail.be>  wrote:
+>>      
+>>> ok, i guess when people said, supported, i immediately assumed full
+>>> support. that kind of misled me.
+>>>        
+>> My understanding, is that backports will have minimal testing.
+>>
+>> We ensure the backport will install, on a system that currently
+>> only has release + updates, and that the basic functions of the
+>> package work, where it's possible for us to test.
+>>
+>> We cannot possibly test every possible combination of selected
+>> backports, and will not attempt to.
+>>
+>> What I don't want to see, which I did with Mandriva backports,
+>> is cases where unsigned rpm packages were in the repositories,
+>> or installation required the use of --allow-nodeps or --allow-force,
+>> due to file conflicts with release or updates packages.  Those
+>> problems were rare, but often enough, that I wouldn't let the end
+>> users I support install backports themselves.
+>>      
+> well, imho even with this testing it's still possible, allthough likely rarer
+> that the user would have to use these or any other manual procedures. even
+> with updates.
+>
+> (unsigned rpms should be caught by the build process, even though it still
+> sometimes fails for reasons unbeknownst)
+>
+> in any case, i don't think of this as supported and won't suggest backports to
+> any user who doesn't have the necessary skills to fix it himself.
+>    
+
+Note that it depends what we mean by support.
+In terms of support that would be provided by an expensive commercial 
+entity that specializes in support, some might argue that our release 
+packages aren't supported.
+
+For backports, there is the understanding that in addition to being 
+tested by QA (after initial packager and end-user tests), that the 
+packager would commit to providing security updates as necessary.  This 
+is much more than "no support at all", as happened with mdv backports.
+
+Considering that each backport will be a leaf package (or exceptionally, 
+a leaf group of related packages), any breakage that would occur should 
+only affect the backport (or backport group) in question.
+
+In terms of updates to backports, which I think is a good idea for 
+security fixes, any conflicts introduced should be rare.  In those 
+cases, indeed updates could fail.  But I don't think it is much more 
+likely than with packages from release or update repos.
+
+Note that an end-user installing the occasional backport, to provide a 
+specific function desired, should not generally cause any problems.  
+Even for an end-user with minimal skills.  As long as the user 
+understands that backports have a lower level of support.  We have the 
+discuss list and the forum to help the end-user in the case of problems.
+
+In sum, I like the idea of saying "tested by QA", as Claire proposed, 
+which suggests the lower level of support we propose for backports.
+
+My 2 cents :)
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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