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

[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.

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