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

Sun Dec 11 17:11:52 CET 2011

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€
+