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
