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

[Mageia-dev] Backports Summary

+ AL13N + alien at rmail.be +
+ Wed Jun 27 08:26:16 CEST 2012 +

+
+ +
Op dinsdag 26 juni 2012 22:25:10 schreef Thomas Backlund:
+> So,
+> we have been discussing this many times, and not gotten any
+> satisfactory decision to go ahead yet...
+[...]
+> Now a point that got raised during discussion of bug 2317:
+> * if a backport break because of something ending up in /updates
+>    it's a bug to be reported against the backport (and not against
+>    the released update) as packages ending up in /updates are only
+>    validated against /release and /updates (and rightfully so as
+>    thats how they are built too)
+
+* in the rare event that an update breaks because of something ending up in 
+/backports before the update was done, the users who had installed that 
+backport, will either need to install the new dependency that's in /release, 
+by replacing it with it's backported version manually. or will have to remove 
+the backport manually to allow the update to be installed.
+
+I'm just giving this for reference, it should be added to the policy imho.
+
+[...]
+> And since we can continue this what/if discussion forever,
+> and thereby delay backports even more here is my take on it:
+> 
+> my suggestions to decide on question 1 and 2:
+> 1. backporting bigger version to mga1 than mga2 has is
+>     allowed as it will otherwise restrict backporting
+>     too much. (and since its leaf packages, it should
+>     not break (too much)). Lets just make it clear to
+>     everyone using backports.
+> 
+> 2. we cant really require that as the one backporting
+>     the package to mga1 has to backport it to mga2 too
+>     as he/she might not be using mga2 at all. if someone
+>     wants/needs the backport for mga2, they need to
+>     request that. (in reality, going by how backports
+>     got handled in mdv most backports will end up in
+>     all supported releases anyway)
+
+I agree either way here. your suggestion is fine for me, another solution is 
+also fine
+
+> If we can agree on this as a start, we can open backports
+> soon so we get actual facts of how backports policy and
+> process works.
+> 
+> Then we rewiew backports policy and process in ~6 months,
+> and adjust it if needed.
+
+I agree with you fully, except for the addendum and bug 2317. iinm QA 
+requested that bug 2317 would be fixed before backports opens, because it'll 
+make their job harder.
+
+the patch i proposed was not good enough, so someone with more in-depth 
+knowledge of perl-urpm than myself needs to take a look at things.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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