[Mageia-dev] Backports Summary

Wed Jun 27 09:47:36 CEST 2012

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é
+
+