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

[Maarten Vanraes]

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?