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/2011-June/006141.html | 116 +++++++++++++++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-June/006141.html (limited to 'zarb-ml/mageia-dev/2011-June/006141.html') diff --git a/zarb-ml/mageia-dev/2011-June/006141.html b/zarb-ml/mageia-dev/2011-June/006141.html new file mode 100644 index 000000000..ca1ee6771 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006141.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] Backports policy proposal + + + + + + + + + +

[Mageia-dev] Backports policy proposal

+ andre999 + andr55 at laposte.net +
+ Wed Jun 29 21:19:00 CEST 2011 +

+
+ +
Michael Scherer a écrit :
+> Le lundi 27 juin 2011 à 21:42 -0400, andre999 a écrit :
+>> Michael Scherer a écrit :
+>>>
+>>> Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit :
+>>>> Michael Scherer a écrit :
+>>
+>> [...]
+>>
+>>>>> - cannot be backported if the package was just created and is thus basically untested in cauldron
+>>>>
+>>>> What about corner cases where a potential backport is incompatible with changes introduced in
+>>>> cauldron ?  Should we leave such packages to third parties ?  (I would tend to say yes.)
+>>>
+>>> Give a more precise example.
+>>
+>> Suppose leaf package fooa depends on foob.  foob is part of the current release.
+>> Cauldron replaces foob with fooc.  fooa is incompatible with fooc.
+>
+> Then why do we replace foob by it in the first place if this break fooa ?
+
+(see below)
+
+>> fooa is requested by some users, and future versions of fooa are intended to be
+>> compatible with fooc.
+>> In this case, even though it wouldn't be testable in cauldron, it could be tested in
+>> backports-testing, and I think it could be a good idea to allow it.
+>>
+>> Even if fooc compatibility wouldn't be available for the next Mageia release, a user
+>> could avoid updating for a release in order to keep using fooa.
+>> However, if there were no intention to make fooa compatible with fooc, maybe it should
+>> be denied.
+>
+> The example is bogus. If we have fooa in the distro and we upload fooc
+> that break it, then we have to fix the breakage as a priority. Usually,
+> that would be having foob and fooc as parallel installablable.
+
+The idea is that fooa is not in release, but is compatible with release, and not with 
+cauldron.  (More details below.)
+
+> Anyway, the question is "how often does it" happens ? Because "it may
+> happen" is not a justification" if in practice, it never happen. And not
+> having a backport is not the end of the world so unless the problem is
+> quite frequent ( and so far, this one is far from being frequent ,
+> especially since it is based on a wrong supposition in the first part ),
+> I do not think this would be blocking.
+
+Often enough there will be changes in cauldron to newer packages not entirely compatible 
+with the older ones they are replacing.  And other existing packages are dependant on 
+them, so they have to be fixed in cauldron.
+Backport requests could be compatible with release but not cauldron.  I wouldn't expect 
+that to be frequent, but such requests have already happened.
+In some cases the updates for compatibility from upstream could just be late in coming.
+
+The question is, should we allow such backports under certain circumstances ?
+I'm not necessarily saying yes.
+Maybe we should say not for now, to be reviewed later ?
+
+-- 
+André
+
+ + + +
+

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