[Mageia-dev] Backports Summary

[Thomas Backlund]

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