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

Sat Dec 10 17:09:24 CET 2011

Michael Scherer skrev 10.12.2011 13:32:
+> 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
+
+
+Policy is to always keep Cauldron with atleast higher release,
+so next release will be ok.
+
+I guess when we have 2 releases we must extend the policy to
+state that if you backport to Mageia 1 you also must backport
+to Mageia 2 in order to keep upgrading fully possible.
+
+
+> - no security  )
+
+
+Well, that's the same as with current stable relase,
+maintainer/backporter submits security fixes to backports_testing
+
+QA validates, update gets pushed.
+
+>
+> 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.
+>
+
+Yep, no argument here....
+
+
+>> 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.
+>
+
+Well, branching is needed, regardless if it's done in a whole separate
+branch as I suggested, or in a branch per package when needed.
+
+> 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.
+>
+
+It cant always be the same in cauldron and backports.
+
+>
+> 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.
+>
+
+If you cant commit to the branch, it's useless.
+
+> - backports are only submitted from the branch, with separate
+> markrelease, tags, whatever. This let us have proper audit of backports,
+> and who did what.
+>
+
+the same auditing is available in any branch or cauldron.
+
+> - 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 ).
+>
+
+Sorry, buth this wont work in reality...
+
+Consider this:
+
+version X in Mageia 1
+version X+1 in Cauldron
+
+version X+1 gets backported.
+
+version X+2 uploaded in Cauldron
+version X+2 cant be backported (depends on updated libs/packages in 
+Cauldron, and we dont backport libs that can break working setups)
+
+version X+1 in backports need to be fixed (security/maintenance fix)
+(here your logic breaks down, there is no place to fix it)
+
+
+And since we aim for quality backports, the maintainer may want to
+stay with version X+1 in backports even if X+2 could be backported
+if maintainer think X+2 isn't a good candidate for some reason.
+
+--
+Thomas
+