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

[Thomas Backlund]

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