[Mageia-dev] Proposal of a backporting process

Wed Jun 29 21:19:42 CEST 2011

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