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

Angelo Naselli anaselli at linux.it
Sun Dec 11 11:41:02 CET 2011


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  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/mageia-dev/attachments/20111211/665a6e8b/attachment.asc>


More information about the Mageia-dev mailing list