[Mageia-dev] Mirror layout, round two

Mon Nov 29 14:56:20 CET 2010

Le lundi 29 novembre 2010 à 13:14 +0100, Samuel Verschelde a écrit :
+>
+> It was said early that you just have to look at whether the package 
+> has a maintainer or not to make a distinction, but this is not sufficient. 
+> A maintainer can be very active in cauldron but not care about maintaining 
+> for stable releases. A package can have no maintainer but be actively 
+> supported in practice (by everybody in cauldron, by security team in 
+> stable releases).
+>
+> The current main vs contrib approach in mandriva is very sensible. It has some (minor, to me) 
+> drawbacks, but when I install packages from main I *know* there will be security updates, 
+> bugfix updates, and a QA process that packages in contrib don't have. 
+
+Since we pull lots of deps ( like perl module, python module ) to ensure
+that everything build fine without any formal check of packages, I can
+ensure you that packages in main do not have more QA process than
+anything. 
+
+What is checked is a list of functionality in the default installation.
+Not every possible feature using every possible package in main.
+
+
+Almost all community distros have found that what you call "minor"
+drawbacks are in fact not a good idea. Fedora merged core and extras.
+Debian never did the split, Gentoo either. The split is usually just a
+reminiscence of the commercial nature of the main sponsor ( Mandriva,
+Ubuntu ).
+
+Let me remind the problems that we are having with the split, as they
+are not so minor :
+- complexity on build system side to take in account this
+  - packagers time lost to understand what going on when self
+    containment is broken. Older ones do not have the problem ( or at
+    least, know it ), but newer one sooner or later does.
+
+- complexity on the users system as they need to have twice the number
+  of media to cope with this. This also appear in the interface of
+  various tools, and it is imho uneeded. Most people will say that we
+  already have too much medias.
+
+- complexity because users do not understand it. If we tell
+
+- time lost managing it. moving from contribs to main, and cleaning
+  main. Main cleaning that is seldomly done because :
+   - no one has time to do it
+   - people fiercly defend the inclusion of their favorite software in
+       main 
+
+- time lost because packagers have to wait on overloaded sysadmin to do 
+  the move
+
+- complexity over time of support because package move from main to
+   contribs and viceversa. Especially when there is some backports from
+   a software in main that would requires a software in contribs, etc.
+
+
+
+> Do we plan to have no QA process at all in Mageia ? 
+
+You should not use this kind of formulation, this is FUD.
+
+> If we plan to have such processes, does the merge between core and extra 
+> make is efficient ? I guess we don't plan to have all packages (even 
+> maintained ones) equally supported with a full QA process (doesn't seem realistic) ?
+
+Again, reread the mail I sent. This is a user concern, not a mirror
+admin concern. As such, it should not leak on mirror organisation,
+neither on BS organisation. 
+And the filtering proposal I made could perfectly fit, provided we find
+a way to get the "QA note" for a package. Maybe a webapp, with 
+
+If some users only want to have only "QA approved package", that's
+rather easy. Just install nothing outside of the default set of
+packages.
+
+> Packages in core get the "QA approved" stamp whereas packages in extra get none.
+
+The self containment requirement would make it very hard to get such QA
+approved stamp. 
+
+We cannot have a package being tested without doing the same for its
+requires first. And we cannot say that we support a package without
+supporting the full requires. 
+
+Look at openoffice at Mandriva. It does requires
+tomcat5-servlet-2.4-api, hsqldb on 2010.1 . They are both non trivial to
+test, and I am quite sure that they were not much "QA approved" besides
+"openoffice work for basic tasks". And in fact, when eclipse was in
+main, this was the same.
+
+So in order to have openoffice to have a QA approved stamp, openjdk,
+tomcat and hsqldb would have one. I am pretty sure they do not had
+extensive checks..
+ 
+-- 
+Michael Scherer
+
+