[Mageia-dev] Backports policy proposal

Fri Jun 24 02:10:14 CEST 2011

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
+
+