[Mageia-dev] Update of backport, policy proposal

Thu Jun 30 15:59:21 CEST 2011

+Le vendredi 24 juin 2011 02:15:03, Michael Scherer a écrit :
+> Hi,
+> 
+> The last mail from the backport trilogy. And like all good trilogy,
+> that's where the suspens is present ( as for the 1 and 2 part, you know
+> there is another episode )
+> 
+> This mail is about handling update on the backport repository. Either
+> new version, or bugfix, or security upgrade.
+> 
+> Everybody was focused on "should we do patch, or should we do more
+> backport" issue, but the real problem is not really here.
+> 
+> First, we have to decide what kind of update do we want to see, among
+> the 3 types :
+> - bugfixes
+> - security bug fixes,
+> - new version
+
+As I said in another thread, I think that for backports we can allow ourselves 
+to rely more heavily on the upstream projects than we do for stable updates.
+
+- we try to provide the new upstream stable versions when asked for and 
+conform to the policy
+- we guarantee support for packaging bugs (those are "our" bugs)
+- for bugs :
+-- they are fixed in a new upstream stable version : we provide it.
+-- they are not : we don't fix them. We're providing the latest from upstream, 
+those bugs have to be fixed upstream.
+-- complex cases : fix available upstream but in a development branch and no 
+release soon, or new version non backportable for technical or policy reasons 
+=> we patch
+-- of course nothing prevents diligent packagers from going farther and 
+putting more energy in bug fixing when upstream is failing, but it's not what 
+we promise to do for all backports.
+- security bugs : I see 2 options. The easier for us is to treat them like the 
+other bugs : rely on upstream fixes. Maybe this gives an acceptable level of 
+risk. The other solution is a "full" security process similar to the one we 
+have for stable updates. I would start with the first one and see later if we 
+can switch to the second one.
+
+For comparison, the level of support for stable updates is :
+- we try to bring as little changes to the package as possible, with the ideal 
+situation being not having to issue updates at all,
+- we guarantee support for packaging bugs (those are "our" bugs)
+- for bugs :
+-- they are fixed upstream : we backport patches from upstream newer releases, 
+or provide upstream new stable bugfix-only releases. Occasionnally a non bugfix-
+only new version can be provided, with a sufficient amount of QA and if the new 
+version doesn't change users habits too much.
+-- they are not fixed upstream : we try to fix it ourselves or get patches from 
+other distributions
+- security bugs : fully supported, even more than standard bugs, and without 
+waiting for users to report security bugs.
+
+As we have to explain what the differences in terms of support between updates 
+and backports is, to ourselves but also to users, here is how I would describe 
+it :
+- "updates : report bugs to us first."
+- "backports : ask for a newer stable version if a bug has been fixed there, or 
+report bugs to both the software's developers and us"
+
+
+> 
+> Then as we want to have working backports, I think we need to do test,
+> like we do for normal backports, or updates. This mean someone need to
+> test, besides the packagers.
+> 
+> For the first one, we can assume that if there is a bug, someone will
+> fill it. Then we can assign it to the one that backported to fix the
+> packages, and ask the reporter to test.
+
+Agreed.
+
+> 
+> 
+> For the 3rd one, I guess we can use the same as 1st one. If no one ask,
+> do nothing. If someone ask, do the same as others backports, and erase
+> the previous one.
+
+Agreed.
+
+> 
+> 
+> For the 2nd one, it all depend on how we find out about security issues.
+> A tool like the one used by debian/ubuntu that check for each package if
+> the version is vulnerable or not could help packager to know if a
+> backport requires a fix or not, like this is done for the others
+> packages. 
+
+That could help indeed, such a tool could automatically create a bug report in 
+bugzilla via XML-RPC for example. Useful for stable updates also of course.
+
+> However, this mean that someone will have to check if the bug
+> is fixed, and the question is "who" ( and I do not have a answer that I
+> find good enough yet ). This could even be more tricky if we consider
+> that this can be a version upgrade, and a security fix. Even if we trust
+> the upstream to fix the security issue, we still want to have it
+> working.
+
+That's a good question, given that priority will be given to stable updates 
+testing rather than backports. With a big security team I would say "the 
+security team", but for now I would trust the upstream here.
+
+> 
+> But besides this question, there is a more important problem. If we
+> think that some packages updates are important enough to be sent to user
+> without them asking for explicitly, we cannot let people pick only some
+> packages on demand by disabling backports.
+> 
+> Either backports source is enabled in urpmi, and this would mean that
+> backports are treated like update from a user point of view, or the
+> backports are enabled on demand, meaning that the user is on his own.
+> 
+> Again, I do not have much ideas. A solution would be to have something
+> like portaudit ( http://www.freshports.org/ports-mgmt/portaudit ). So
+> people would be warned if the backport is insecure, or could be upgraded
+> ( even for a new version ). I guess we should however psuh people to run
+> the latest backport, whatever the reason, to avoid headaches when bug
+> are reported.
+> 
+> Another solution would be to patch urpmi to do a special type of update,
+> ie it would only update packages from backports if they come from
+> backports. Not really clean, IMHO.
+
+I don't find this solution that dirty. Let urpmi store a list of package names 
+to be updated from backports. By default it would add every installed backport 
+in it but the user could modify the list at will.
+And if we don't want to modify urpmi's behaviour concerning package update, 
+then we can patch MageiaUpdate.
+
+> 
+> Last solution, declare that cherry picking is not supported, or that
+> people are on their own, and explain the reason. However, people have
+> been asking this, and recommend this. This would also be against a goal
+> of having confidence in the backports.
+
+You already know that would find it a bad solution, given that there other 
+options open to us.
+
+Best regards
+
+Samuel Verschelde
+
+