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
signature.asc
Description: This is a digitally signed message part.