diff options
| author | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
|---|---|---|
| committer | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
| commit | 1be510f9529cb082f802408b472a77d074b394c0 (patch) | |
| tree | b175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-dev/2011-June/006022.html | |
| parent | fa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff) | |
| download | archives-1be510f9529cb082f802408b472a77d074b394c0.tar archives-1be510f9529cb082f802408b472a77d074b394c0.tar.gz archives-1be510f9529cb082f802408b472a77d074b394c0.tar.bz2 archives-1be510f9529cb082f802408b472a77d074b394c0.tar.xz archives-1be510f9529cb082f802408b472a77d074b394c0.zip | |
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/006022.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/006022.html | 169 |
1 files changed, 169 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/006022.html b/zarb-ml/mageia-dev/2011-June/006022.html new file mode 100644 index 000000000..e0e900272 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006022.html @@ -0,0 +1,169 @@ +<!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=%3C1309043079.22020.248.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="006002.html"> + <LINK REL="Next" HREF="006023.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Update of backport, policy proposal</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Update%20of%20backport%2C%20policy%20proposal&In-Reply-To=%3C1309043079.22020.248.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Update of backport, policy proposal">misc at zarb.org + </A><BR> + <I>Sun Jun 26 01:04:38 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="006002.html">[Mageia-dev] Update of backport, policy proposal +</A></li> + <LI>Next message: <A HREF="006023.html">[Mageia-dev] Update of backport, policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6022">[ date ]</a> + <a href="thread.html#6022">[ thread ]</a> + <a href="subject.html#6022">[ subject ]</a> + <a href="author.html#6022">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le vendredi 24 juin 2011 à 18:13 -0400, andre999 a écrit : +><i> Michael Scherer a écrit : +</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>><i> +</I>><i> For bugfixes and new versions, that are not known to have security implications, let's treat them +</I>><i> essentially as new backports. +</I>><i> If the bug were locally reported, the reporter would be involved in the testing. +</I>><i> Such updates would be installed as any other backport. +</I>><i> However I would favour notifying those who have installed previous versions of these backports, of +</I>><i> the availability of newer versions. +</I> +The question is "how". + +><i> Maybe even having a backports updates category. (But not to be installed automatically by default.) +</I>><i> +</I>><i> For security issues, I'm not sure that it is important how we find out. +</I>><i> As far as responsibility, I think the main responibility should be by the packager, but it could be +</I>><i> useful for the security team to monitor it, to find an alternate packager if necessary. +</I>><i> (Presumably from those who have tested or installed the package.) +</I>><i> (I don't know who monitors security issues now, I just assume the security team.) +</I>><i> +</I>><i> However I think that such packages should be tested as normally for backports, and then treated as +</I>><i> security updates, to be automatically applied. +</I> +If we place it in a repository that is enabled by default, we will +basically do a version upgrade for every people that have it enabled. + +If this is updates, this would violate our own policy. + +If we place in backports, it is not enabled by default. + +><i> This is because those who have installed the backport in question have decided to accept a higher +</I>><i> degree of risk. However a security issue can be a much greater risk, and is something that is +</I>><i> normally resolved automatically. So by installing a security bug fix automatically for a backport, +</I>><i> we are essentially maintaining the level of risk already assumed by the user. +</I> +So that basically mean "unsupported". + +There is even more tricky problems : +Let's take a software that release soon, release often. Let's say a voip +software. + +Someone install version 1.0 from release. So far, so good, but he hear +that 1.1 is out, and he install it from backport ( after requesting ). +He is satisfied, then the developers of our voip software decide to +create a version 2.0, with a completely new interface but the ui is yet +unfinished and untranslated, so our user cannot use it. Yet, someone +request a backport, and let's assume we do it. + +With our current scheme, our user will not be affected and he doesn't +want to upgrade. So he keep the version 1.1. + +A security issue is discovered, in 1.X and 2.X. + +1.0-2 is sent to release update, with security fix. +2.1 is sent to backport, as the packager follow the list. + +What should be done for the user : +Force upgrade to the next major release ? +Ask him to revert to release update ? +Tell him "this is not supported" ? + +Or maybe we should not have upgraded to 2.0 if we knew that current user +would refuse it ? + +-- +Michael Scherer + +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="006002.html">[Mageia-dev] Update of backport, policy proposal +</A></li> + <LI>Next message: <A HREF="006023.html">[Mageia-dev] Update of backport, policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6022">[ date ]</a> + <a href="thread.html#6022">[ thread ]</a> + <a href="subject.html#6022">[ subject ]</a> + <a href="author.html#6022">[ 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> |