[Mageia-dev] Backports Summary

[andre999]

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é