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/016288.html | 171 +++++++++++++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-June/016288.html (limited to 'zarb-ml/mageia-dev/2012-June/016288.html') diff --git a/zarb-ml/mageia-dev/2012-June/016288.html b/zarb-ml/mageia-dev/2012-June/016288.html new file mode 100644 index 000000000..a39ae07b5 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-June/016288.html @@ -0,0 +1,171 @@ + + + + [Mageia-dev] Backports policy clarification (and discussion) + + + + + + + + + +

[Mageia-dev] Backports policy clarification (and discussion)

+ andre999 + andre999mga at laposte.net +
+ Fri Jun 8 16:11:07 CEST 2012 +

+
+ +
Sander Lepik a écrit :
+> 08.06.2012 11:38, Samuel Verschelde kirjutas:
+>    
+>> I re-read the backports policy, and there's a part I think needs to be pointed
+>> out before people start to backport packages.
+>>
+>> "We need to ensure that upgrades never fail: cauldron must always have a
+>> higher version/release than in stable releases."
+>>
+>> This statement is true, but implies more than what it says. It means that we
+>> can't backport a package for Mageia 1 with a higher version than what we have
+>> in Mageia 2 release (and updates?) media. And this, until we are able to take
+>> backports into account during upgrades.
+>>
+>> Example :
+>> - Mageia 2 has wesnoth 1.10.2 in core/release
+>> - Mageia 1 can't get a higher version in its backports media
+>>
+>> Do you all agree with my understanding of the policy ?
+>>      
+
+I see your point.
+In most cases, a backport for mga1 would be essentially identical for 
+mga2 (except package file name and corresponding changes in the spec file).
+It would only differ if dependancies differ, which I suspect is unlikely 
+for wesnoth or most other games, for example.
+So this means that for a backport to mga1, we should first do one to mga2.
+This would more than likely be done at the same time by the same 
+packager, so not much more work.
+The demand for backports to mga1 is not likely to be very high, and 
+would depend on a willing packager.
+
+>> This is a serious limitation to our ability to backport to Mageia (n-1) and
+>> even to our ability to provide security fixes to backports there (will not
+>> prevent it, but will prevent to do it by a version upgrade, which is the
+>> common way to fix that kind of issue in backports).
+>>      
+
+If we already have a backport with versions in mga2 and mga1, applying 
+security fixes to both would not likely be much more involved than only 
+to mga2.  If it only applies to mga1, as long as the version is lower 
+than that in mga2, we can always ensure that the version of the update 
+remains lower.  Similarly for mga2 with respect to cauldron.
+
+>> Maybe we shouldn't open backports for Mageia 1, and make sure upgrade to
+>> Mageia 3 can take backports from Mageia 2 into account so that backports to
+>> Mageia 2 are not stopped when Mageia 3 is released. Then we'll be safe.
+>>      
+
+Not to worry :)
+>> Samuel
+>>      
+> I think backports should be open until new stable is released. So we should not open
+> backports for mga1 and when mga2 is released then backports for mga2 will be closed.
+> It's the only way we can manage upgrades with our current packager resources.
+>    
+
+A backport isn't going to happen without a packager willing to package 
+it.  There is no point in arbitrarily blocking backports to supported 
+releases for this reason.
+Although I would agree that there is not likely to be many backports to 
+mga1, because of this and the lower priority in QA, as well as the 
+understanding that the user requesting the backport would be implicated 
+in testing it.
+
+> --
+> Sander
+>
+>    
+-- 
+André
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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