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
