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

[Florian Hubold]

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.