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

Sun Dec 11 18:43:35 CET 2011

Am 11.12.2011 17:11, schrieb 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€
+>
+Whatever the decision is, maybe we could tie this to some conditions:
+Only allow backports if there are near-zero security/critical bugs for the
+stable release or if there are no open bugs for the package in question?
+Just some random crazy idea ...
+
+IMHO we should focus on security and bugfixes for the stable release,
+and there are currently too many security bugs open, some for a
+really long time, where nothing is happening for months, yet we still
+talk and concern about opening backports.
+