[Mageia-dev] Backports Summary

Thu Jun 28 09:57:00 CEST 2012

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