[Mageia-dev] Update of backport, policy proposal

[Michael Scherer]

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