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

[Maarten Vanraes]

Op zondag 11 december 2011 11:41:02 schreef Angelo Naselli:
> sabato 10 dicembre 2011 alle 17:09, Thomas Backlund ha scritto:
> > 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.
> 
> So, couldn't we consider backports in the same way as updates?
> The only difference is that they go into another branch, and they
> need to have a higher version than in updates and lower than cauldron.
> 
> Tests and validations follow the same rules, if a backport is not
> validated won't be pushed.
> Is that more work for QA? unfortunately yes, but i do hope tests
> and validations can be done by more users interested in that
> update/backport.
> 
> Why using backports instead of updates then? because for some reasons
> we -or maintainers- don't want to push as update a new version.
> I'm not really in favour of a strict release update, we have already
> pacakges not doing that (leaf ones, or those that are a pain to patch like
> ff for instance,...).
> In such a way backports is not going to be seen as a potential breakage of
> the system, but as a part of distro life.
> 
> A problem i can see though is if a maintainer decides that a version
> that has been backported can become an update, even if it can be
> managed by working on release version, that update is svn and HD room
> effect...
> 
> Angelo

you can have new version as updates.

backporting is the addition of new features and thus the possibility of new 
bugs, even with QA, you can't completely get the same level of stability from 
updates, as you get from backports...

but that's fine. it doesn't need to be, it's not enabled by default, it'd be 
nice if those work well.

what we really want is for backports to be suggested in rpmdrake on a case by 
case basis.

since fixing bugs is more important that adding new features and some people do 
updates, but don't want any risk, it's completely valid that they are 
separate.

i just vote that we make a svn backports branch, (NOT a separate repos, it'd 
be nice if we can just branch it, which doesn't use any extra disk space), for 
some packages it means we can add a patch on backports to make it work for 
mga1 specifically and still merge patches from cauldron into backports if we 
want (or wherever we branch from)

we should however keep matches close at a hand, in case people do weird 
things, some automated checks could be done and possibly mailed somewhere to 
show that suspicious activity is going on... if it's tmb, we know we can 
ignore it then.

i think this is by far the most flexible solution, and we should try to keep 
our level of maintainers high, but informing them of where it can go wrong, 
what they should look for...

just my 0.02€