[Mageia-dev] Backports policy proposal

[Michael Scherer]

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