[Mageia-dev] Update of backport, policy proposal

Sun Jun 26 01:04:38 CEST 2011

Le vendredi 24 juin 2011 à 18:13 -0400, andre999 a écrit :
+> Michael Scherer a écrit :
+> >
+> > 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
+> 
+> For bugfixes and new versions, that are not known to have security implications, let's treat them 
+> essentially as new backports.
+> If the bug were locally reported, the reporter would be involved in the testing.
+> Such updates would be installed as any other backport.
+> However I would favour notifying those who have installed previous versions of these backports, of 
+> the availability of newer versions.
+
+The question is "how". 
+
+> Maybe even having a backports updates category.  (But not to be installed automatically by default.)
+> 
+> For security issues, I'm not sure that it is important how we find out.
+> As far as responsibility, I think the main responibility should be by the packager, but it could be 
+> useful for the security team to monitor it, to find an alternate packager if necessary.
+> (Presumably from those who have tested or installed the package.)
+> (I don't know who monitors security issues now, I just assume the security team.)
+> 
+> However I think that such packages should be tested as normally for backports, and then treated as 
+> security updates, to be automatically applied.
+
+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.
+
+> This is because those who have installed the backport in question have decided to accept a higher 
+> degree of risk.  However a security issue can be a much greater risk, and is something that is 
+> normally resolved automatically.  So by installing a security bug fix automatically for a backport, 
+> we are essentially maintaining the level of risk already assumed by the user.
+
+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
+
+