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

Sat Dec 10 14:00:21 CET 2011

Op zaterdag 10 december 2011 12:32:12 schreef Michael Scherer:
+> 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.
+[...]
+> > And to be honest I dont see that changing anytime soon...
+> 
+> Then we have a bigger problem to solve.
+
+This is likely correct, i think we have shortage of people in various parts, 
+but perhaps sysadmin (which is arguably the most important team), has not 
+enough active people to follow up all the issues (or they are busy with other 
+teams).
+
+because other teams are counting on sysadmin team and even though it's all on 
+svn, it's not that easy (i think; at least for me) to learn this system and 
+put some patches for sysadmin to follow, perhaps sysadmin team should grow a 
+bit more people.
+
+[...]
+> > 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.
+
+I think there are more incentives than just that for backports, at least imho.
+
+plus, if the problem is you don't know where it's from, perhaps we should fix 
+that problem instead of having an arguably less flexible solution. also, iirc, 
+when branching svn, afaik it mentions where it's been branched from?
+ 
+> 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.
+
+for me this solution would be ok, but iirc tmb requires for kernel a bit more 
+flexibility?
+
+and tbh, having a more dirty spec file is not something i'd wish for...
+
+but, even if this is a nice solution, we still have the problem listed above 
+that we'd get backports since before mageia1 and it's still not here? since 
+it's also not the priority (updates are more important) what chances do we 
+have of actually having backports before mga2?
+