[Mageia-dev] Update of backport, policy proposal

[Samuel Verschelde]

Le vendredi 24 juin 2011 02:15:03, Michael Scherer a écrit :
> Hi,
> 
> The last mail from the backport trilogy. And like all good trilogy,
> that's where the suspens is present ( as for the 1 and 2 part, you know
> there is another episode )
> 
> 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

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"


> 
> Then as we want to have working backports, I think we need to do test,
> like we do for normal backports, or updates. This mean someone need to
> test, besides the packagers.
> 
> For the first one, we can assume that if there is a bug, someone will
> fill it. Then we can assign it to the one that backported to fix the
> packages, and ask the reporter to test.

Agreed.

> 
> 
> For the 3rd one, I guess we can use the same as 1st one. If no one ask,
> do nothing. If someone ask, do the same as others backports, and erase
> the previous one.

Agreed.

> 
> 
> For the 2nd one, it all depend on how we find out about security issues.
> A tool like the one used by debian/ubuntu that check for each package if
> the version is vulnerable or not could help packager to know if a
> backport requires a fix or not, like this is done for the others
> packages. 

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.

> However, this mean that someone will have to check if the bug
> is fixed, and the question is "who" ( and I do not have a answer that I
> find good enough yet ). This could even be more tricky if we consider
> that this can be a version upgrade, and a security fix. Even if we trust
> the upstream to fix the security issue, we still want to have it
> working.

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.

> 
> But besides this question, there is a more important problem. If we
> think that some packages updates are important enough to be sent to user
> without them asking for explicitly, we cannot let people pick only some
> packages on demand by disabling backports.
> 
> Either backports source is enabled in urpmi, and this would mean that
> backports are treated like update from a user point of view, or the
> backports are enabled on demand, meaning that the user is on his own.
> 
> Again, I do not have much ideas. A solution would be to have something
> like portaudit ( http://www.freshports.org/ports-mgmt/portaudit ). So
> people would be warned if the backport is insecure, or could be upgraded
> ( even for a new version ). I guess we should however psuh people to run
> the latest backport, whatever the reason, to avoid headaches when bug
> are reported.
> 
> Another solution would be to patch urpmi to do a special type of update,
> ie it would only update packages from backports if they come from
> backports. Not really clean, IMHO.

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.

> 
> Last solution, declare that cherry picking is not supported, or that
> people are on their own, and explain the reason. However, people have
> been asking this, and recommend this. This would also be against a goal
> of having confidence in the backports.

You already know that would find it a bad solution, given that there other 
options open to us.

Best regards

Samuel Verschelde