[Mageia-dev] Backports policy proposal

[Michael Scherer]

Hi,

as said, this is the 2nd mail of the 3 mails about handling backports.
It is about backport policy, ie what we update, and what we don't, with
a set of criteria, to make sure we fullfill our goals.

I will start by the fact we can all agree that we want to have a
breakage-free experience. One of the value of the project is the
quality, and traditionally, the best way to not break something is to
have minimal changes.
Yet, people have asked for newer version of packages, and people are ok
to trade a little bit of change and little bit of risk for new software,
and we have offered that in the past at Mandriva with some success.

Experience have showed that people care mostly about applications rather
than low level library and modules. Experience have also show that
people are not sure about backport, and that we should make sure
everything work fine so we can have more people that use them.

The Mandriva policy was rather good, and I think we can also all agree
there is packages that can clearly not be backportable without either
lots of QA, or without rebuilding lots of stuff :
- glibc, python, perl, xorg, etc

I would also say that the maintainer can also say that he doesn't want
the rpm be backported, either because he think that's not ready, or
because he think it should not be done. I think this will not happen
often, but for the rare case a problem would arise, the maintainer
should have the last word.

On the other hand, there is packages that can be backported without
impacting much :
- leaf packages ( those that nothing requires ), 
- packages not present in the distribution ( provided it doesn't
obsolete or provides stuff that would impact the distribution, like
backporting a new jvm with a obsolete on the current one ).

So for a start, I would suggest to use the same policy as Mandriva
( http://wiki.mandriva.com/en/Policies/SoftwareMedia#Backports_policy ).

Ie, only create a backport for rpm  that cannot have a negative impact
( leaf packages, newer one ), and then revise the policy in one year
based on request that were refused, to see if we can find something to
change.


I would also propose a few rules :

"a package should have been in cauldron since 1 week before being
backported", so we can at least ensure there was a minimal test on it,
Ie, if I package stuff-virtual-manager, I cannot backport it before 1
week. If we have a package of stuff-virtual-manager since 1 month, and
that I update a new version, then I can backport. The idea is that a
newer packages may suffer from more bug than older one.


Another rule that we could add is that cauldron should always be newer
than backports, in order to ensure upgradability. The same goes for n-2
and n-1 release.
While this seems innocent, do not forget this will have a impact when we
do the version freeze.


Something that was discussed previously, we should make sure that
backport can be cherrypicked. If I backport trac, I will need to place
stricted Requires from subpackages on the main package and so on, in
order to ensure no mix of rpm. And since we plan to backport only leaf
packages, this would not affect others packages. However, this will have
a impact on the next issue, updates.

so :
- cannot be backported if this is not a leaf package, will be revised
later
- cannot be backported if the maintainer say "no", but we assume he say
"yes" by default
- cannot be backported if it impact the dependency tree too much
( Obsoletes, Provides, etc )
- cannot be backported if the package was just created and is thus
basically untested in cauldron

- must not prevent upgrade to next release 

- strict requires between backported packages, in order to make sure
they can be cherrypicked ( ie, someone enable backports, install, remove
backports )

You can comment ( do not forget to trim the answer , and please keep
this on topic, that's why I did 3 mails ).

-- 
Michael Scherer