Thomas Backlund a écrit :
Thomas Backlund skrev 26.6.2012 22:25:
So,
we have been discussing this many times, and not gotten any
satisfactory decision to go ahead yet...
First off, we decided long ago that backports will be
better supported than during mdv times, meaning security
and bugfixes and has to pass QA.
Now for references:
* we have the backports policy:
https://wiki.mageia.org/en/Backports_policy
* Last discussions started by Stormi:
* [Mageia-dev] Backports policy clarification (and discussion)
https://www.mageia.org/pipermail/mageia-dev/2012-June/016265.html
* [Mageia-dev] Proposed Feature:Backports_update_applet
https://www.mageia.org/pipermail/mageia-dev/2012-June/016263.html
* It also came up in the discussion about fixing bug 2317:
* [Mageia-dev] bug 2317 revisited: --update option should behave
like
--search-media
https://www.mageia.org/pipermail/mageia-dev/2012-June/016692.html
People seem to agree on most things, but there is a few questions
that need to be decided how to handle.
Lets start with the summary and suggestion of how to get it started:
(addendum / refinements / important points of current backports policy)
* backports is supported as long as the rest of the release
* packages must always be in cauldron first
* if you want to backport a package someone else is maintainer
for, you need to discuss with maintainer first. if he dont
want the package to be backported _and_ have valid reasons,
respect that. (if you disagree, you can still ask council)
* if you backport anything, (regardless if you are the real
maintainer or not) you accept the responsibility of
handling the bugreports against the backport and make sure
it gets patched (or upgraded) to get security fixes.
* cherrypicking backports must work, so requires need
to be checked and be strict to make sure they work
* nothing in backports must require the use of "--nodeps"
or "--force" to get it to install
* QA will do basic tests to make sure it works and obeys the rules
* QA can deny package(s) to be backported if it breaks the policy
* QA has /updates as priority, and /backports will be handled
if/when there is time, so if you want faster response, join QA
to help out with the workload.
Now a point that got raised during discussion of bug 2317:
* if a backport break because of something ending up in /updates
it's a bug to be reported against the backport (and not against
the released update) as packages ending up in /updates are only
validated against /release and /updates (and rightfully so as
thats how they are built too)
And some important points to avoid making backports_testing a
"dumping ground" for package(r)s trying to avoid the policy:
* after submitting anything to backports_testing you have
48 hours to file/assign a "Backport to validate" at
bugs.mageia.org.
* package needs to be validated within 1 month (or shorter/longer
time if QA wants that)
* failure to match any of the two timelimits will get the
package removed from updates_testing again. (I understand this
This should have stated "backports_testing"
will get some questions, but if we cant get people to help out
with QA we might as well never open backports)
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
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.
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.
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.
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.
--
Thomas
.
--
André
