[Mageia-dev] Backports Summary

[andre999]

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é