[Mageia-dev] Mirror layout, round two

Tue Nov 30 14:45:56 CET 2010

Samuel Verschelde skrev 30.11.2010 13:04:
+>
+> Le mardi 30 novembre 2010 11:37:42, Thomas Backlund a écrit :
+>>
+>> So, after reading all different opinions here and discussing with
+>> founders, here is the idea:
+>>
+>> We start of with  3 medias: core, nonfree, tainted and 3 debug medias:
+>> debug_core, debug_nonfree, debug_tainted. In order to avoid confusion,
+>> we wont use the name "restricted" as it was used in MDV commercial products.
+>>
+>> Now all of theese medias will have their 5 submedias: release, updates,
+>> updates_testing, backports, backports_testing.
+>>
+>> That brings us to 30 medias in total :)
+>>
+>> The details of the media layout suggestion is also at the end of this
+>> mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy
+>>
+>>
+>> Now...
+>>
+>> We wont blindly import every package from cooker, instead  we'll
+>> start off the import with basesystem (as in bootable system with
+>> shell access), compiler and rpm tools (and of course their buildtime
+>> depencies). When all of that is imported and rebuilt, we have a working
+>> buildsystem / base to build from.
+>>
+>> Then we to go on with and start importing X, the different
+>> DE's and every other package needed to build a full distro.
+>>
+>> By doing it this way, we get a clean start, every package rebuilt,
+>> and no old/unmaintained stuff in the beginning.
+>>
+>> Then as more maintainers join, I guess more packages will be imported
+>> from cooker and other sources. And packages can always be requested.
+>>
+>> As for those that want the core/extra split:
+>> We already tried it with main/contrib split. And I know mdv is now
+>> trying to refine what belongs in main or not, but thats for mdv
+>> to work through the "problem" as it wont be an easy task.
+>>
+>> For us I think the best way for now is to start with this suggested
+>> layout, and see if it works well for us. Remember, as Michael pointed
+>> out, this is a community supported distro, and only time will tell how
+>> well the community actually will support their distro.
+>>
+>> Point is, if we later decide this is not working well, we can always
+>> review the decisions and if decided do the split.
+>>
+>> Can we reach an agreement that this is the way to start the distro?
+>>
+>
+> OK for me provided support policy matters are not discarded forever but only delayed to allow things to start.
+>
+
+It wont be discarded.
+We need to list package priority, wich ones must go through QA, and wich 
+ones that are subject to maintainer qa & testing
+
+> It would be great to start QA Team's organization as soon as possible. I don't think we need to wait for the BS and the packages to begin thinking about those matters.
+>
+
+Yes, its time to start defining policies around all this and team creation.
+
+--
+Thomas
+