[Mageia-dev] Backports Summary

[Thomas Backlund]

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)
>
>
>
> 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 ?
>
> --
>
> Thomas
> .
>