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

Tue Jan 3 10:45:13 CET 2012

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
+