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