diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/006163.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/006163.html | 205 |
1 files changed, 205 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/006163.html b/zarb-ml/mageia-dev/2011-June/006163.html new file mode 100644 index 000000000..89455ca6f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006163.html @@ -0,0 +1,205 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Update of backport, policy proposal + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Update%20of%20backport%2C%20policy%20proposal&In-Reply-To=%3C201106301559.21438.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="006077.html"> + <LINK REL="Next" HREF="006165.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Update of backport, policy proposal</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Update%20of%20backport%2C%20policy%20proposal&In-Reply-To=%3C201106301559.21438.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Update of backport, policy proposal">stormi at laposte.net + </A><BR> + <I>Thu Jun 30 15:59:21 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="006077.html">[Mageia-dev] Update of backport, policy proposal +</A></li> + <LI>Next message: <A HREF="006165.html">[Mageia-dev] Update of backport, policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6163">[ date ]</a> + <a href="thread.html#6163">[ thread ]</a> + <a href="subject.html#6163">[ subject ]</a> + <a href="author.html#6163">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE> +Le vendredi 24 juin 2011 02:15:03, Michael Scherer a écrit : +><i> Hi, +</I>><i> +</I>><i> The last mail from the backport trilogy. And like all good trilogy, +</I>><i> that's where the suspens is present ( as for the 1 and 2 part, you know +</I>><i> there is another episode ) +</I>><i> +</I>><i> This mail is about handling update on the backport repository. Either +</I>><i> new version, or bugfix, or security upgrade. +</I>><i> +</I>><i> Everybody was focused on "should we do patch, or should we do more +</I>><i> backport" issue, but the real problem is not really here. +</I>><i> +</I>><i> First, we have to decide what kind of update do we want to see, among +</I>><i> the 3 types : +</I>><i> - bugfixes +</I>><i> - security bug fixes, +</I>><i> - new version +</I> +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" + + +><i> +</I>><i> Then as we want to have working backports, I think we need to do test, +</I>><i> like we do for normal backports, or updates. This mean someone need to +</I>><i> test, besides the packagers. +</I>><i> +</I>><i> For the first one, we can assume that if there is a bug, someone will +</I>><i> fill it. Then we can assign it to the one that backported to fix the +</I>><i> packages, and ask the reporter to test. +</I> +Agreed. + +><i> +</I>><i> +</I>><i> For the 3rd one, I guess we can use the same as 1st one. If no one ask, +</I>><i> do nothing. If someone ask, do the same as others backports, and erase +</I>><i> the previous one. +</I> +Agreed. + +><i> +</I>><i> +</I>><i> For the 2nd one, it all depend on how we find out about security issues. +</I>><i> A tool like the one used by debian/ubuntu that check for each package if +</I>><i> the version is vulnerable or not could help packager to know if a +</I>><i> backport requires a fix or not, like this is done for the others +</I>><i> packages. +</I> +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. + +><i> However, this mean that someone will have to check if the bug +</I>><i> is fixed, and the question is "who" ( and I do not have a answer that I +</I>><i> find good enough yet ). This could even be more tricky if we consider +</I>><i> that this can be a version upgrade, and a security fix. Even if we trust +</I>><i> the upstream to fix the security issue, we still want to have it +</I>><i> working. +</I> +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. + +><i> +</I>><i> But besides this question, there is a more important problem. If we +</I>><i> think that some packages updates are important enough to be sent to user +</I>><i> without them asking for explicitly, we cannot let people pick only some +</I>><i> packages on demand by disabling backports. +</I>><i> +</I>><i> Either backports source is enabled in urpmi, and this would mean that +</I>><i> backports are treated like update from a user point of view, or the +</I>><i> backports are enabled on demand, meaning that the user is on his own. +</I>><i> +</I>><i> Again, I do not have much ideas. A solution would be to have something +</I>><i> like portaudit ( <A HREF="http://www.freshports.org/ports-mgmt/portaudit">http://www.freshports.org/ports-mgmt/portaudit</A> ). So +</I>><i> people would be warned if the backport is insecure, or could be upgraded +</I>><i> ( even for a new version ). I guess we should however psuh people to run +</I>><i> the latest backport, whatever the reason, to avoid headaches when bug +</I>><i> are reported. +</I>><i> +</I>><i> Another solution would be to patch urpmi to do a special type of update, +</I>><i> ie it would only update packages from backports if they come from +</I>><i> backports. Not really clean, IMHO. +</I> +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. + +><i> +</I>><i> Last solution, declare that cherry picking is not supported, or that +</I>><i> people are on their own, and explain the reason. However, people have +</I>><i> been asking this, and recommend this. This would also be against a goal +</I>><i> of having confidence in the backports. +</I> +You already know that would find it a bad solution, given that there other +options open to us. + +Best regards + +Samuel Verschelde + +</PRE> + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="006077.html">[Mageia-dev] Update of backport, policy proposal +</A></li> + <LI>Next message: <A HREF="006165.html">[Mageia-dev] Update of backport, policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6163">[ date ]</a> + <a href="thread.html#6163">[ thread ]</a> + <a href="subject.html#6163">[ subject ]</a> + <a href="author.html#6163">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |