[Mageia-dev] Proposal of a backporting process

[andre999]

Michael Scherer a écrit :
> Le mercredi 29 juin 2011 à 10:56 +0200, Angelo Naselli a écrit :
>> mercoledì 29 giugno 2011 alle 00:23, andre999 ha scritto:
>>> A leaf package is a package that is not required by any other package.
>>> But leaf packages will always require something else.
>>> If B requires A, then A is not a leaf package, even though B could be.
>>> When backporting B, we test to make sure that it works with release A.
>>> Obviously it restricts what can be backported, but the trade-off is that backports will
>>> (almost always) work, and they won't break anything.
>>
>> Well my point is i often backport something for my job (for the most
>> commoncpp2 now, ucommon in future), and since they are libraries i can fall
>> in errors. I always tested before backporting though, and i haven't had any problems
>> upgrading, but that's me and i could have been lucky.
>>
>> If we can accept some exceptions from time to time, but proved (bug open, testing
>> and updates/backports etc) i can think to have mageia not only at home or in a virtual
>> box. Otherwise i can't see the need of backports, for me of course.
>
> If we start to add exception while we do not even have started to agree
> on the general case, we are never gonna go anywhere :)
>
> I have the impression that everybody want to be able at the same time to
> backport anything, and yet expect to have the same level of support and
> quality, and without using any more ressources.
>
> Technically, anything could be backported with proper tests. After all,
> that's roughly the process we use for cauldron ( ie, take a new version
> of software, compile it on the distribution, and build later others
> software against that ).
>
> Every software have someone interested, from low level like kernel
> ( backported on kernel-linus, asked by people as seen on MIB ), or gcc
> ( gcc 4.6 being my main motivation for keeping a cooker installation )
> to higher level like gajim or midori. The only thing that no one would
> be interested is stuff that do not move ( at, linpng, etc ), ie
> everything were there is no new features, and working fine. And even,
> people could want to have a new feature, such as systemd, etc.
>
> So in the end, if we want to satisfy everybody, the answer is to have no
> policy forbidding anything and just say "do proper amount of QA". That's
> fine by me ( especially since I do not use backports ), but we have to
> agree on that.

I see this as an argument for having simple, clean basic rules (the "general case"), on 
which we can have well-defined exceptions, some (or all) of which may require 
case-by-case approval.

So let's accept the initial proposal as the base rules.
Then define some well-defined exceptions, for use cases that fall outside these base 
rules.  And whether each particular exception should require case-by-case approval.

-- 
André