[Mageia-dev] RFC: Opening Backports (once again...)

[Buchan Milne]

On Saturday, 10 December 2011 13:32:12 Michael Scherer wrote:
> Le mardi 06 décembre 2011 à 00:56 +0200, Thomas Backlund a écrit :
> > Now,
> > 
> > here comes the question about backports once again.
> > 
> > We are now 6+ months into Mageia 1, and we are nowhere closer to opening
> > backports that we were at Mageia 1 release time.
> > 
> > Because of that there are 3rdparty repos popping up everywhere...,
> > something we hoped to avoid atleast partly when starting this project.
> 
> Well, the backport issue ( ie :
> - no garantee of keep the distribution upgradable

Backports will probably provide a better probability of upgradability than 
3rd-party repos.

> - no security  )

No means to provide a security updates that has followed a QA process in the 
event package version Z no longer builds on distribution with version X in 
release and version Y in backports.

But, note that without backports, users who wanted version Y would either:
-Switch to a distro that has version Y (worse) - I would guess 20%
-Switch to using cauldron, and start contributing (better) - I would guess 5% 
or less
-Use Cauldron package on stable release (worse) - I would guess about 30%
-Build package from source (worse) - I would guess about 20%
-Rebuild cauldron package on stable release (same) - I wold guess about 10%
-Keep version X (better) and eventually become upset about age of software 
(worse) - I would guess about 15%

So, only one outcome would be better, one would be the same, and the other 3 
outcomes would be worse, and probably be the majority of outcomes.

In the case where there is no problem with providing the update, backports is 
superiour, and would provide a better outcome in every case.

Do we have any idea on how many packages this ever affected in Mandriva?

> have also not been fixed, so that's rather unfair to

... ?

> > So here is a suggestion to get some value to our endusers:
> > 
> > we add a backports branch on svn
> > 
> > So packages for backports would use:
> > 
> > svn.mageia.org/packages/backports/1/<package>/{current,pristine,releases}
> > 
> > and allow that to be used for backports.
> > 
> > Using a separate branch is also a cleaner way of providing
> > backports, and makes it easy to separate changes needed only
> > for Cauldron (or backports).

I thought the whole point of Backports was to provide a streamlined way to 
provide newer versions of packages that already exist in Cauldron, with 
minimal effort, to stable releases. This increases the incentive for users on 
stable releases to contribute to Cauldron in some way, and doesn't increase 
the burden on the maintainer significantly. There should be no need to have 
distribution release-specific content in any of the packages.

In the rare case a package can't be provided like this, maybe it isn't a good 
candidate for backports?

> Then in practice, that mean having a 2nd/3rd distribution ( because
> there is a separate 2nd svn branch, and a 3rd one for later ) and so
> that's a big no for me. Having 2+ branchs is just asking for trouble
> when they are not in sync ( and since keeping everything in sync
> properly with svn is a pain if there is a divergence, this will not be
> done ).
> 
> Worst, if we do like in mdv and propose 2 way of backporting ( submit
> from cauldron, submit from a branch ), this will create a mess of having
> some packages from cauldron, some from the branch, and people having no
> way from knowing where does a package come from. This also make the
> system harder to maintain and to follow, and rather impossible to script
> properly.
> 
> So that's also to be avoided.
> 
> Having a separate branch where people can write also remove the only
> incentive I have seen for backports, ie, wider testing of our packages,
> because they may not really the same as in cauldron.
> 
> 
> So here is what I propose :
> 
> - have X branchs, but do not let anyone commit on it, besides a system
> user. When a package is submitted to cauldron, it is also copied to this
> branch, ie, we make sure current is in sync. The same goes for version
> N-1 being copied from N once a backported rpm have been submitted to be
> used by people. Once a distribution is no longer supported, we close the
> branch, and disable the sync.
> 
> - backports are only submitted from the branch, with separate
> markrelease, tags, whatever. This let us have proper audit of backports,
> and who did what.
> 
> - packagers still need to commit and submit on cauldron before any
> backports. So we miss no fixes or anything by mistake. We also make sure
> that cauldron is always the highest version possible, thus permitting at
> least some form of upgrade. ( either stable to stable, provided
> backports are used, or stable to cauldron ). And we also ensure that
> backports are done first on the most recent stable version, for the same
> reason ( ensure some form of upgrade path, as asked several time by
> users ).

So, we have two copies of identical packages, that are always in sync, and can 
never diverge.

What is the point then? Just to allow build system rules not to be violated 
(by using a branch)?

> And we can still use %ifdef if a need arise for a different spec between
> distribution versions. While that make spec less readable, that's more
> readable than having forked specs 2 or 3 times.
> 
> This requires :
> 
> - 1 youri action to copy the package to current backport branch ( can be
> done based on the markrelease action and the others )
> 
> - 1 svn configuration to prevent people from writing directly there ( or
> just say to not do it, and burn people who do it )
> 
> 
> - youri config to let people submit from backports to backports_testing.

What does this all achieve that would not be achieved by allowing submission 
from cauldron to backports_testing ?

Regards,
Buchan