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

Sat Dec 10 12:32:12 CET 2011

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
+- no security  )
+
+have also not been fixed, so that's rather unfair to 
+
+> And at current rate we will probably release Mageia "infinity"
+> before backports is opened.
+> 
+> 
+> It has been delayed because of needed infrastructure changes,
+> something no-one have had time to do so far...
+> 
+> I know there is "only some coding missing" and "someone should
+> do it", buth truthfully there are only a few that knows the
+> code used in the buildsystem enough to actually make it happend,
+> and they are already othervise busy or overloaded...
+> (this is no rant against them, as all here are using their
+>   personal free time to help out)
+> 
+> And to be honest I dont see that changing anytime soon...
+
+Then we have a bigger problem to solve.
+
+> 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).
+
+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 ).
+
+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.
+
+
+-- 
+Michael Scherer
+
+