[Mageia-dev] Backports Summary

Wed Jun 27 12:46:12 CEST 2012

andre999 skrev 27.6.2012 10:47:
+> Thomas Backlund a écrit :
+>> Thomas Backlund skrev 26.6.2012 22:25:
+
+>>>
+>>> And then the questions we need to decide on:
+>>> (substitute mga1/mga2 for any future release...)
+>>> 1. Do we support backporting package with higher version
+>>>       than package in the following next mageia release has ?
+>>>       (meaning if mga1 has v12, and mga2 has v14, is it ok
+>>>        to backport v16 to mga1?)
+>>>       * PRO: more uptodate package in backports
+>>>       * CON: can cause trouble during distro upgrade
+>>>       * imho both technically ok as long as we make sure
+>>>         its documented so people know what to expect.
+>>>
+>>> 2. If one want to backport a package to mga1, does it mean
+>>>       it must be backported to mga2 in order to preserve
+>>>       upgrade path (unless already in mga2, depending on
+>>>       question 1)?
+>>>
+>>>
+>>>
+>>> 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 would favour adding the requirement that the dependancies of the
+> backport must be available in the next release.  So that we would expect
+
+
+This is esentially stating that we cant backport any bigger version to 
+mga2 /backports than mga3 will havein /release wich means when we hit 
+version freeze for mga3, it also freezes mga2 /backports...
+
+
+> that the backport would continue to function properly on an update to
+> the next release, but we don't require that it be tested, so it may not.
+
+-ENOTCOMPUTE
+
+"continue to function properly" vs "don't require that it be tested"
+
+> This is a relatively simple to check, so it won't have a big impact on
+> QA, but should increase significantly the reliability of backports.
+>
+
+Nothing is "simple" if it's supposed to "continue to function properly"
+as it then must be tested.
+
+>>> 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.
+>>>
+>>>
+>>>
+>>> Comments? Questions ?
+>
+> I would favour tagging backports as update repos, so that in the event
+> of a newer backport for security or bug fixes, that it will be
+> automatically presented with other updates.
+
+No.
+as the update applet currently works it would show the backport as
+an update even if you dont have an earlier backport installed,
+defeating the purpose of having separate /updates vs /backports
+
+> This would require some modification to update tools, so it seems to me
+> ok to open backports beforehand, with the understanding that the update
+> tools would be changed to accommodate this.
+
+Tools must work before the backports repo affect them.
+
+--
+Thomas
+