diff options
Diffstat (limited to 'zarb-ml/mageia-dev/attachments/20101201')
6 files changed, 384 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/attachments/20101201/1604e755/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20101201/1604e755/attachment-0001.html new file mode 100644 index 000000000..ac501300a --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101201/1604e755/attachment-0001.html @@ -0,0 +1,75 @@ +<br><br><div class="gmail_quote">2010/12/1 Maarten Vanraes <span dir="ltr"><<a href="mailto:maarten.vanraes@gmail.com">maarten.vanraes@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +Op dinsdag 30 november 2010 13:31:08 schreef Samuel Verschelde:<br> +> Hi,<br> +><br> +> I would like to discuss the support policy for Mageia.<br> +><br> +> It would be interesting to know (or decide) where Mageia is heading, given<br> +> our limited resources : 1) focus on stability and security : few very well<br> +> equally supported packages. Apparently, this is where we're going for now.<br> +> May be wise as a start, but I hope this is not our final destination,<br> +> because it means either very limited choice, or progressive diminution of<br> +> quality of support if the number of packages increases faster than the<br> +> dedicated resources. 2) focus on choice : many packages, but no support<br> +> policy. This would be really bad, I think we're not heading there, from<br> +> what I read. However, this is a danger if we start from option 1) and then<br> +> open wide the gates for importing packages, without setting a support<br> +> policy. 3) focus on both (this is my option). There would be 2 levels of<br> +> support : - top guaranteed support : those are the (few at start) packages<br> +> your can rely on almost blindly, they'll be updated in a timely manner,<br> +> and updates don't break things. Those are the packages the QA Team puts<br> +> its limited resources on (doesn't mean the QA Team provides the support<br> +> themselves, this is maintainer work, but they check that good support is<br> +> provided) : testing, helping the maintainers to watch for security<br> +> problems... The maintainers are responsible for their package, but the QA<br> +> Team double-checks updates for stable releases. - supported packages<br> +> (every other package) : those are maintained packages, however the QA Team<br> +> doesn't have to check them. It's up to the maintainer to check the package<br> +> and updates quality. - unsupported packages are dropped.<br> +><br> +> Are we heading for 1), 2), 3), or any other option ?<br> +><br> +> Of course, with unlimited resources, options 1 and 3 would be equivalent,<br> +> everything would have the "top guaranteed support" :)<br> +><br> +> Best regards<br> +><br> +> Samuel Verschelde<br> +> Packager/QA Team/User<br> +<br> +<br> +having read misc's lenghty and almost political proposal, i suggest a 4th<br> +option (even though i'm not part of QAteam either):<br> +<br> +4) dynamically distributed focus:<br> +- level 1: BuildSystem-required packages (all packages used for buildnodes)<br> +- level 2: everything that is minimally required to boot and do stuff<br> +- level 3: popular server packages<br> +- level 4: release focus (everything that's defaultly installed by a release)<br> +- level 4b: stage images<br> +- level 5: the rest<br> +<br> +depending on resources and certain timings; focus should be spread according<br> +to desires at that time.<br> +<br> +eg:<br> +- i imagine that level 1 could be discussed between sysadm and qateam during<br> +BS-updates<br> +- i imagine that level 2 would be the primary focus<br> +- i imagine that level 4 could be more important during release times<br> +- i imagine that level 5 would probably not be focussed by QA unless unlimited<br> +resources<br> +- i imagine that level 3 would probably be good if resources would be growing,<br> +and possibly level 4 if there's enough resources.<br> +<br> +<br> +- i agree that testing should be open to anyone<br> +- i agree that karma could not be a bad idea, but suggest that QAteam give<br> +more karma (perhaps even on the karmic state of that person)<br> +- i also would suggest that at the time of alpha release, we should do a<br> +contest on testing and bugfinding; so that we could gather enough testers; and<br> +possibly even extra packagers or qateam people.<br> +<br> +WDYT?<br> +</blockquote></div><br><br clear="all">Option 4 sounds good, it also shows a little bit the responsibilities of each team.<br>I would like to add a level 3b which differs between server-only and desktop.<br><br><br>-- <br> +Mit freundlichen Grüßen<br><br>Greetings<br><br>Daniel Kreuter<br><br><br><br> diff --git a/zarb-ml/mageia-dev/attachments/20101201/1604e755/attachment.html b/zarb-ml/mageia-dev/attachments/20101201/1604e755/attachment.html new file mode 100644 index 000000000..ac501300a --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101201/1604e755/attachment.html @@ -0,0 +1,75 @@ +<br><br><div class="gmail_quote">2010/12/1 Maarten Vanraes <span dir="ltr"><<a href="mailto:maarten.vanraes@gmail.com">maarten.vanraes@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +Op dinsdag 30 november 2010 13:31:08 schreef Samuel Verschelde:<br> +> Hi,<br> +><br> +> I would like to discuss the support policy for Mageia.<br> +><br> +> It would be interesting to know (or decide) where Mageia is heading, given<br> +> our limited resources : 1) focus on stability and security : few very well<br> +> equally supported packages. Apparently, this is where we're going for now.<br> +> May be wise as a start, but I hope this is not our final destination,<br> +> because it means either very limited choice, or progressive diminution of<br> +> quality of support if the number of packages increases faster than the<br> +> dedicated resources. 2) focus on choice : many packages, but no support<br> +> policy. This would be really bad, I think we're not heading there, from<br> +> what I read. However, this is a danger if we start from option 1) and then<br> +> open wide the gates for importing packages, without setting a support<br> +> policy. 3) focus on both (this is my option). There would be 2 levels of<br> +> support : - top guaranteed support : those are the (few at start) packages<br> +> your can rely on almost blindly, they'll be updated in a timely manner,<br> +> and updates don't break things. Those are the packages the QA Team puts<br> +> its limited resources on (doesn't mean the QA Team provides the support<br> +> themselves, this is maintainer work, but they check that good support is<br> +> provided) : testing, helping the maintainers to watch for security<br> +> problems... The maintainers are responsible for their package, but the QA<br> +> Team double-checks updates for stable releases. - supported packages<br> +> (every other package) : those are maintained packages, however the QA Team<br> +> doesn't have to check them. It's up to the maintainer to check the package<br> +> and updates quality. - unsupported packages are dropped.<br> +><br> +> Are we heading for 1), 2), 3), or any other option ?<br> +><br> +> Of course, with unlimited resources, options 1 and 3 would be equivalent,<br> +> everything would have the "top guaranteed support" :)<br> +><br> +> Best regards<br> +><br> +> Samuel Verschelde<br> +> Packager/QA Team/User<br> +<br> +<br> +having read misc's lenghty and almost political proposal, i suggest a 4th<br> +option (even though i'm not part of QAteam either):<br> +<br> +4) dynamically distributed focus:<br> +- level 1: BuildSystem-required packages (all packages used for buildnodes)<br> +- level 2: everything that is minimally required to boot and do stuff<br> +- level 3: popular server packages<br> +- level 4: release focus (everything that's defaultly installed by a release)<br> +- level 4b: stage images<br> +- level 5: the rest<br> +<br> +depending on resources and certain timings; focus should be spread according<br> +to desires at that time.<br> +<br> +eg:<br> +- i imagine that level 1 could be discussed between sysadm and qateam during<br> +BS-updates<br> +- i imagine that level 2 would be the primary focus<br> +- i imagine that level 4 could be more important during release times<br> +- i imagine that level 5 would probably not be focussed by QA unless unlimited<br> +resources<br> +- i imagine that level 3 would probably be good if resources would be growing,<br> +and possibly level 4 if there's enough resources.<br> +<br> +<br> +- i agree that testing should be open to anyone<br> +- i agree that karma could not be a bad idea, but suggest that QAteam give<br> +more karma (perhaps even on the karmic state of that person)<br> +- i also would suggest that at the time of alpha release, we should do a<br> +contest on testing and bugfinding; so that we could gather enough testers; and<br> +possibly even extra packagers or qateam people.<br> +<br> +WDYT?<br> +</blockquote></div><br><br clear="all">Option 4 sounds good, it also shows a little bit the responsibilities of each team.<br>I would like to add a level 3b which differs between server-only and desktop.<br><br><br>-- <br> +Mit freundlichen Grüßen<br><br>Greetings<br><br>Daniel Kreuter<br><br><br><br> diff --git a/zarb-ml/mageia-dev/attachments/20101201/7249ee28/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20101201/7249ee28/attachment-0001.html new file mode 100644 index 000000000..7852d57e6 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101201/7249ee28/attachment-0001.html @@ -0,0 +1,83 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<html> + <head> + <meta content="text/html; charset=ISO-8859-1" + http-equiv="Content-Type"> + <title></title> + </head> + <body text="#000000" bgcolor="#ffffff"> + On 01.12.2010 00:12, Maarten Vanraes wrote: + <blockquote cite="mid:201012010012.04846.maarten.vanraes@gmail.com" + type="cite">Le mardi 30 novembre 2010 11:37:42, Thomas Backlund a + écrit :<br> + <blockquote type="cite"> + <blockquote type="cite"> + <pre wrap="">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: <a class="moz-txt-link-freetext" href="http://mageia.org/wiki/doku.php?id=mirrors_policy">http://mageia.org/wiki/doku.php?id=mirrors_policy</a> + + +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? +</pre> + </blockquote> + <br> + </blockquote> + </blockquote> + I have one question at your suggestion Thomas.<br> + Mandriva has editions like Mandriva One or Mandriva Free. Will there + be something different or will Mageia use this as a base?<br> + <br> + I would prefer that some proprietary firmware will be available such + as the WIFI drivers of Intel (iwlwifi) , which is needed by my + wireless card, without choosing the correct version of Mageia.<br> + These drivers are also available in the kernel right now, so it + would be a possibility to activate them there by default so newer + hardware will work <span id="result_box" class="short_text" + lang="en"><span style="color: rgb(0, 0, 0);" title="">correctly.</span></span><br> + <br> + Daniel<br> + <br> + </body> +</html> diff --git a/zarb-ml/mageia-dev/attachments/20101201/7249ee28/attachment.html b/zarb-ml/mageia-dev/attachments/20101201/7249ee28/attachment.html new file mode 100644 index 000000000..7852d57e6 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101201/7249ee28/attachment.html @@ -0,0 +1,83 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<html> + <head> + <meta content="text/html; charset=ISO-8859-1" + http-equiv="Content-Type"> + <title></title> + </head> + <body text="#000000" bgcolor="#ffffff"> + On 01.12.2010 00:12, Maarten Vanraes wrote: + <blockquote cite="mid:201012010012.04846.maarten.vanraes@gmail.com" + type="cite">Le mardi 30 novembre 2010 11:37:42, Thomas Backlund a + écrit :<br> + <blockquote type="cite"> + <blockquote type="cite"> + <pre wrap="">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: <a class="moz-txt-link-freetext" href="http://mageia.org/wiki/doku.php?id=mirrors_policy">http://mageia.org/wiki/doku.php?id=mirrors_policy</a> + + +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? +</pre> + </blockquote> + <br> + </blockquote> + </blockquote> + I have one question at your suggestion Thomas.<br> + Mandriva has editions like Mandriva One or Mandriva Free. Will there + be something different or will Mageia use this as a base?<br> + <br> + I would prefer that some proprietary firmware will be available such + as the WIFI drivers of Intel (iwlwifi) , which is needed by my + wireless card, without choosing the correct version of Mageia.<br> + These drivers are also available in the kernel right now, so it + would be a possibility to activate them there by default so newer + hardware will work <span id="result_box" class="short_text" + lang="en"><span style="color: rgb(0, 0, 0);" title="">correctly.</span></span><br> + <br> + Daniel<br> + <br> + </body> +</html> diff --git a/zarb-ml/mageia-dev/attachments/20101201/9aa255f5/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20101201/9aa255f5/attachment-0001.html new file mode 100644 index 000000000..efe539f33 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101201/9aa255f5/attachment-0001.html @@ -0,0 +1,34 @@ +<br><br><div class="gmail_quote">2010/12/1 Buchan Milne <span dir="ltr"><<a href="mailto:bgmilne@multilinks.com">bgmilne@multilinks.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +On Tuesday, 30 November 2010 18:09:38 Michael Scherer wrote:<br> +> Le mardi 30 novembre 2010 à 16:36 +0100, Samuel Verschelde a écrit :<br> +<br> +> ><br> +> > Well, I can't because as you already told me we don't know what our<br> +> > resources will be. What I can guess is that they are limited because I<br> +> > know no free software project where there's too much resources.<br> +><br> +> Well, from a physical point of view, everything is limited, so saying<br> +> "limited ressources" didn't indeed told much.<br> +<br> +[...]<br> +<br> +> But still, having community enabled QA is a great way to have every grow<br> +> properly.<br> +> And in fact, that's exactly one of the feature of your project<br> +> mageia-app-db. So we could indeed have a better QAteam by easing the<br> +> work of community, using mageia-app-db. Ie, take regular user, and turn<br> +> them in QA team member.<br> +<br> +BTW., this is one reason why I would prefer a Mageia user or contributor to<br> +have one account, for everything. It reduces the obstacles becoming a<br> +contributor. A user who post on the forum has a bugzilla account and a wiki<br> +account and should be able to provide feedback on packages etc.<br> +<br> +Only when the user needs to be able to push changes somewhere without<br> +authorization of another contributor, does the user need to request privileged<br> +access (but, on the same account).<br> +<br> +Regards,<br> +<font color="#888888">Buchan<br> +</font></blockquote></div><br>Nice idea, something like that would be a nice thing. Who wants to register for 5 pages only to become a full member of a community? Nobody. <br clear="all"><br><br>-- <br>Mit freundlichen Grüßen<br> +<br>Greetings<br><br>Daniel Kreuter<br><br><br><br> diff --git a/zarb-ml/mageia-dev/attachments/20101201/9aa255f5/attachment.html b/zarb-ml/mageia-dev/attachments/20101201/9aa255f5/attachment.html new file mode 100644 index 000000000..efe539f33 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101201/9aa255f5/attachment.html @@ -0,0 +1,34 @@ +<br><br><div class="gmail_quote">2010/12/1 Buchan Milne <span dir="ltr"><<a href="mailto:bgmilne@multilinks.com">bgmilne@multilinks.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +On Tuesday, 30 November 2010 18:09:38 Michael Scherer wrote:<br> +> Le mardi 30 novembre 2010 à 16:36 +0100, Samuel Verschelde a écrit :<br> +<br> +> ><br> +> > Well, I can't because as you already told me we don't know what our<br> +> > resources will be. What I can guess is that they are limited because I<br> +> > know no free software project where there's too much resources.<br> +><br> +> Well, from a physical point of view, everything is limited, so saying<br> +> "limited ressources" didn't indeed told much.<br> +<br> +[...]<br> +<br> +> But still, having community enabled QA is a great way to have every grow<br> +> properly.<br> +> And in fact, that's exactly one of the feature of your project<br> +> mageia-app-db. So we could indeed have a better QAteam by easing the<br> +> work of community, using mageia-app-db. Ie, take regular user, and turn<br> +> them in QA team member.<br> +<br> +BTW., this is one reason why I would prefer a Mageia user or contributor to<br> +have one account, for everything. It reduces the obstacles becoming a<br> +contributor. A user who post on the forum has a bugzilla account and a wiki<br> +account and should be able to provide feedback on packages etc.<br> +<br> +Only when the user needs to be able to push changes somewhere without<br> +authorization of another contributor, does the user need to request privileged<br> +access (but, on the same account).<br> +<br> +Regards,<br> +<font color="#888888">Buchan<br> +</font></blockquote></div><br>Nice idea, something like that would be a nice thing. Who wants to register for 5 pages only to become a full member of a community? Nobody. <br clear="all"><br><br>-- <br>Mit freundlichen Grüßen<br> +<br>Greetings<br><br>Daniel Kreuter<br><br><br><br> |