[Mageia-dev] Backports Summary

[Buchan Milne]

On Tuesday, 26 June 2012 22:25:10 Thomas Backlund wrote:
> So,
> we have been discussing this many times, and not gotten any
> satisfactory decision to go ahead yet...

Sorry for the late reply, but as some of you are aware, I have had some 
problems replying to Mageia-related mails (which are finally resolved).

> First off, we decided long ago that backports will be
> better supported than during mdv times,

This may be an unfair generalisation.

> meaning security
> and bugfixes and has to pass QA.

In some cases, this is a basic feature of backports. For example, the primary 
targets of my backports typically ship new releases for any security fix, and 
bugfixes are typically released in new releases (and only in severe cases do 
we cherry-pick the bugfix from a new release for a bugfix update).

In the case of samba, openldap etc., my primary motivation for wanting 
backports is so that we can provide early bugfixes (which in most cases have 
been well tested by the rest of the upstream community) with less delay than 
cherry-picking bugfixes, QA, etc.

The other motivation for me, is to make newly packaged software in cauldron 
available to stable releases. The probability of a security update being 
required is usually quite low in this case.

> Now for references:
> * we have the backports policy:
>    https://wiki.mageia.org/en/Backports_policy

I think we are over-engineering everything here.

See for example:
https://www.google.com/search?q=%22main/backports%20openldap-2.4%22%20site:lists.mandriva.com

For openldap, since upstream doesn't really look at bugs on old releases, I 
backported every new release to every version that had a build system 
available.

In all that time, there was only ever one bug reported on the backports, due 
to a NMU backport.

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

But this is not a committment to always backport every already-backported 
package.

> * packages must always be in cauldron first

Of course.

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

Agreed, but it is not critical to QA every possible combination of packages. 
Users are able to resolve these problems themselves, and report the problem.

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

Hmm, in many cases, I actually test backports on the stable release myself 
before submitting them ... I am concerned QA will become a bottle-neck that 
doesn't necessarily always add much value.

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

I would prefer if we could crowd-source and automate this, otherwise, again, 
this will be the bottle-neck.

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

As long as it was backported to mga2 first.

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

E.g., if upgrading from mga1 to mga2 and having used backports  after mga2 
release, the users should enable backports in mga2 during upgrade, or post-
upgrade.

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

Yes.

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

What about an update to a backport for a security issue?

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

Typically, if it backports easily to mga1, it will backport more easily to 
mga2.

> 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 think we may want to review this policy one month after we open backports, 
as I think some pieces in the process/policy may not scale as well as the 
others.

Regards,
Buchan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/mageia-dev/attachments/20120628/42c04d86/attachment-0001.html>