[Mageia-dev] Backports Summary

[Thomas Backlund]

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