[Mageia-dev] Backports policy proposal

Sun Jun 26 00:41:44 CEST 2011

Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit :
+> Michael Scherer a écrit :
+> >
+> > 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
+> 
+> What about corner cases where a potential backport is incompatible with changes introduced in 
+> cauldron ?  Should we leave such packages to third parties ?  (I would tend to say yes.)
+
+Give a more precise example.
+
+> > - must not prevent upgrade to next release
+> 
+> I can see where a backport could be a more recent version than in cauldron for the moment.  Since 
+> that could make the newer version available to users somewhat sooner.  Although by release, 
+> cauldron should have at least as recent a version.  Or should we prohibit this ?
+> (I'm thinking of cases where more recent versions are expected for cauldron before release.)
+
+If we decide to use the spec from cauldron on stable ( as it seems to be
+the sanest way of doing it ), the only way to have a newer version in
+stable than in cauldron would be to have the build broken on cauldron.
+
+If we tolerate this, and if no one fix ( because the person that did the
+upgrade only care about stable release ), we have a broken build.
+
+So forcing the build to be correct on cauldron would be a stronger
+incentive to fix. It seems more desirable to prevent a backport if the
+price to pay is to have a potentially broken cauldron package.
+
+
+> > - strict requires between backported packages, in order to make sure they can be cherrypicked ( ie, someone enable backports, install, remove backports )
+> 
+> It would be best if one can select individual backports without activating the backports 
+> repositories, as is now the case.
+> So only the brave (wanting all backports) need activate the backports repositories.
+> 
+> Agree with everything, except as noted.
+> 
+> It might be useful to list major packages that should never be backported.
+> I like the idea of tagging backports in the package name, as well as in the package database.
+
+We cannot tag in the packages database. Yum do it with a separate sqlite
+file, afaik.
+
+And tagging in the package name would be quite tricky to do if we need
+to play with %mkrel and release.
+
+
+-- 
+Michael Scherer
+
+