[Mageia-dev] Backports Summary

Wed Jun 27 13:40:50 CEST 2012

Thomas Backlund a écrit :
+> 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...
+
+I'm not following this point.
+What I mean is that if backport xx for mga1 requires yy version 12 in 
+mga1, but yy is version 13 in mga2, we would define the requires for yy 
+to accept versions 12 to 13 (or maybe wider).
+If the user updates to mga2, yy would be updated to version 13, and the 
+backport would still be expected to work (without being tested).  Of 
+course it is possible that it doesn't for some reason, as it hasn't been 
+tested.  But adding this requirement makes it much more likely to work.
+
+If there is a further update to mga3, the backport would be replaced by 
+what was the cauldron package, which would have the appropriate requires.
+
+>> 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"
+
+See my explanation above.
+
+>> 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.
+
+My point is simply that if we ensure that the backport requires match 
+what is available in the next release, then it is more likely to work 
+than if we don't meet this condition.
+I'm not saying that it "must" continue to function properly, only that 
+it is more likely to.
+There are many cases where the available packages change, and it 
+required packages are no longer available, it could be more prudent to 
+deny the backport.
+Just a suggestion.
+
+>>>> 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 is conditional on first modifying the update tools, as suggested next.
+A backport should only update an already installed backport.
+(Similarly for nonfree and tainted, if that is not already the case.)
+>
+>> 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.
+
+I agree that it would be very much better to modify the tools first.
+Just suggesting that as an alternative, if we are in a hurry to open 
+backports.
+
+> -- 
+> Thomas
+>
+-- 
+André
+
+