diff options
Diffstat (limited to 'zarb-ml/mageia-dev/attachments/20101001')
14 files changed, 214 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/attachments/20101001/188c7ba6/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20101001/188c7ba6/attachment-0001.html new file mode 100644 index 000000000..ba50c8731 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101001/188c7ba6/attachment-0001.html @@ -0,0 +1,11 @@ +<br><br><div class="gmail_quote">2010/10/1 Thierry Vignaud <span dir="ltr"><<a href="mailto:thierry.vignaud@gmail.com">thierry.vignaud@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> +On 1 October 2010 12:52, Olivier Blin <<a href="mailto:mageia@blino.org">mageia@blino.org</a>> wrote:<br> +> But actually, just moving to git could make contributions easier,<br> +> because of the ability for developpers to commit locally, and push<br> +> incremental patchsets.<br> +<br> +It's easier for us developers but more difficult for translators that<br> +learned to use SVN (which was easy for them to swtich from CVS since<br> +the commands were similar)<br> +</blockquote></div><br><div>Well, as KDE experience shows, SVN and Git are not incompatible, i.e. you can have SVN for translators, even if some development are done in Git.</div><div>And, second, if we could use e.g. Transifex, then underlying VCS is mostly irrelevant to the translators (though experienced ones who have proper permissions could also interact directly with underlying VCS, be it SVN or Git, if needed).</div> +<div><br></div><div>Marek Laane</div><div><br></div> diff --git a/zarb-ml/mageia-dev/attachments/20101001/188c7ba6/attachment.html b/zarb-ml/mageia-dev/attachments/20101001/188c7ba6/attachment.html new file mode 100644 index 000000000..ba50c8731 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101001/188c7ba6/attachment.html @@ -0,0 +1,11 @@ +<br><br><div class="gmail_quote">2010/10/1 Thierry Vignaud <span dir="ltr"><<a href="mailto:thierry.vignaud@gmail.com">thierry.vignaud@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> +On 1 October 2010 12:52, Olivier Blin <<a href="mailto:mageia@blino.org">mageia@blino.org</a>> wrote:<br> +> But actually, just moving to git could make contributions easier,<br> +> because of the ability for developpers to commit locally, and push<br> +> incremental patchsets.<br> +<br> +It's easier for us developers but more difficult for translators that<br> +learned to use SVN (which was easy for them to swtich from CVS since<br> +the commands were similar)<br> +</blockquote></div><br><div>Well, as KDE experience shows, SVN and Git are not incompatible, i.e. you can have SVN for translators, even if some development are done in Git.</div><div>And, second, if we could use e.g. Transifex, then underlying VCS is mostly irrelevant to the translators (though experienced ones who have proper permissions could also interact directly with underlying VCS, be it SVN or Git, if needed).</div> +<div><br></div><div>Marek Laane</div><div><br></div> diff --git a/zarb-ml/mageia-dev/attachments/20101001/4bd1f76c/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20101001/4bd1f76c/attachment-0001.html new file mode 100644 index 000000000..bf9dddab7 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101001/4bd1f76c/attachment-0001.html @@ -0,0 +1 @@ +I love FireFox for its plethora of add-ons. I wouldn't give it up for any other browser, although it eats up a lot of memory.<br> diff --git a/zarb-ml/mageia-dev/attachments/20101001/4bd1f76c/attachment.html b/zarb-ml/mageia-dev/attachments/20101001/4bd1f76c/attachment.html new file mode 100644 index 000000000..bf9dddab7 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101001/4bd1f76c/attachment.html @@ -0,0 +1 @@ +I love FireFox for its plethora of add-ons. I wouldn't give it up for any other browser, although it eats up a lot of memory.<br> diff --git a/zarb-ml/mageia-dev/attachments/20101001/5e2d4ec6/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20101001/5e2d4ec6/attachment-0001.html new file mode 100644 index 000000000..0019c7bad --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101001/5e2d4ec6/attachment-0001.html @@ -0,0 +1,18 @@ +<br><br><div class="gmail_quote">2010/10/1 Olivier Méjean <span dir="ltr"><<a href="mailto:omejean@yahoo.fr">omejean@yahoo.fr</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;"> +Le vendredi 1 octobre 2010 22:57:06, Maarten Vanraes a écrit :<br> +><br> +> [...]<br> +<div class="im">><br> +> i don't understand, if you click the applet every time there's an update,<br> +>  then when there's a new version, the you also click the applet and it<br> +>  updates... there isn't any real difference from a user pov...<br> +><br> +<br> +</div>Have you ever tried ? I did once and broken (don't remeber when, 2009 → 2009.1<br> +maybe)<br> +<br> +And also it does not answer for OOo 3.2 not being available for Mandriva 2010<br> +<br> +And finally, why waiting for a new version to update, can't it be done<br> +regularly ?<br> +<div><div></div><br></div></blockquote><div><br>mageia can handle better updates/backports but a for a rolling distro just use cauldron :þ <br></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20101001/5e2d4ec6/attachment.html b/zarb-ml/mageia-dev/attachments/20101001/5e2d4ec6/attachment.html new file mode 100644 index 000000000..0019c7bad --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101001/5e2d4ec6/attachment.html @@ -0,0 +1,18 @@ +<br><br><div class="gmail_quote">2010/10/1 Olivier Méjean <span dir="ltr"><<a href="mailto:omejean@yahoo.fr">omejean@yahoo.fr</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;"> +Le vendredi 1 octobre 2010 22:57:06, Maarten Vanraes a écrit :<br> +><br> +> [...]<br> +<div class="im">><br> +> i don't understand, if you click the applet every time there's an update,<br> +>  then when there's a new version, the you also click the applet and it<br> +>  updates... there isn't any real difference from a user pov...<br> +><br> +<br> +</div>Have you ever tried ? I did once and broken (don't remeber when, 2009 → 2009.1<br> +maybe)<br> +<br> +And also it does not answer for OOo 3.2 not being available for Mandriva 2010<br> +<br> +And finally, why waiting for a new version to update, can't it be done<br> +regularly ?<br> +<div><div></div><br></div></blockquote><div><br>mageia can handle better updates/backports but a for a rolling distro just use cauldron :þ <br></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20101001/b5458f4b/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20101001/b5458f4b/attachment-0001.html new file mode 100644 index 000000000..c7e7cf896 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101001/b5458f4b/attachment-0001.html @@ -0,0 +1 @@ +<div dir="ltr">Hello,<br><br>i am glad to be a contributor of the Mandriva _fork_.<br><br><br>zieduz<br></div> diff --git a/zarb-ml/mageia-dev/attachments/20101001/b5458f4b/attachment.html b/zarb-ml/mageia-dev/attachments/20101001/b5458f4b/attachment.html new file mode 100644 index 000000000..c7e7cf896 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101001/b5458f4b/attachment.html @@ -0,0 +1 @@ +<div dir="ltr">Hello,<br><br>i am glad to be a contributor of the Mandriva _fork_.<br><br><br>zieduz<br></div> diff --git a/zarb-ml/mageia-dev/attachments/20101001/c23b4e46/attachment-0001.asc b/zarb-ml/mageia-dev/attachments/20101001/c23b4e46/attachment-0001.asc new file mode 100644 index 000000000..c4bc8f93d --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101001/c23b4e46/attachment-0001.asc @@ -0,0 +1,7 @@ +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.10 (GNU/Linux) + +iF4EAREIAAYFAkymPO4ACgkQC3ySct6ZEpL7JQD9EbVBrTDNZNiRrERKDG47U9J4 +NdtdOE/MUJM8iJbmPbsA/30xmGa3EeB+kXxfA0r0CxAmTYwN5Z6yQjJJsdDr8mhj +=mDlF +-----END PGP SIGNATURE----- diff --git a/zarb-ml/mageia-dev/attachments/20101001/c23b4e46/attachment.asc b/zarb-ml/mageia-dev/attachments/20101001/c23b4e46/attachment.asc new file mode 100644 index 000000000..c4bc8f93d --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101001/c23b4e46/attachment.asc @@ -0,0 +1,7 @@ +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.10 (GNU/Linux) + +iF4EAREIAAYFAkymPO4ACgkQC3ySct6ZEpL7JQD9EbVBrTDNZNiRrERKDG47U9J4 +NdtdOE/MUJM8iJbmPbsA/30xmGa3EeB+kXxfA0r0CxAmTYwN5Z6yQjJJsdDr8mhj +=mDlF +-----END PGP SIGNATURE----- diff --git a/zarb-ml/mageia-dev/attachments/20101001/c90d9d83/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20101001/c90d9d83/attachment-0001.html new file mode 100644 index 000000000..eb63d3fa8 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101001/c90d9d83/attachment-0001.html @@ -0,0 +1,21 @@ +I think that from both a financial and technological point of view Mageia should have two releases a year. With the rate at which Linux technology increases it makes a lot of sense to have a release every 6 months. Also, I do agree that using the year number for each release is very handy.<br> +<br>-Jason A. Turner<br><br><div class="gmail_quote">2010/10/1 Maurice Batey <span dir="ltr"><<a href="mailto:maurice@bcs.org.uk">maurice@bcs.org.uk</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;"> +<div class="im">On Fri, 01 Oct 2010 09:51:34 +0300, atilla ontas wrote:<br> +<br> +> I'm just wondering if we follow Mandriva's release cycle model. Every<br> +> 6th months a release or one year and one release. I think we should<br> +> make one release in one year.<br> +<br> +</div> I feel the same way, but from an income point of view Mageia would<br> +probably be better off with 2 per year.<br> +<div class="im"><br> +> Do we follow Mandriva's release naming scheme? I.e.<br> +> do we call our first release 2011.x ?<br> +<br> +</div> Incorporating the year number is a big help.<br> +<font color="#888888"><br> +--<br> +/\/\aurice<br> +<br> +<br> +</font></blockquote></div><br><div style="visibility: hidden; display: inline;" id="avg_ls_inline_popup"></div><style type="text/css">#avg_ls_inline_popup { position:absolute; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; width: 240px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 13px;}</style> diff --git a/zarb-ml/mageia-dev/attachments/20101001/c90d9d83/attachment.html b/zarb-ml/mageia-dev/attachments/20101001/c90d9d83/attachment.html new file mode 100644 index 000000000..eb63d3fa8 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101001/c90d9d83/attachment.html @@ -0,0 +1,21 @@ +I think that from both a financial and technological point of view Mageia should have two releases a year. With the rate at which Linux technology increases it makes a lot of sense to have a release every 6 months. Also, I do agree that using the year number for each release is very handy.<br> +<br>-Jason A. Turner<br><br><div class="gmail_quote">2010/10/1 Maurice Batey <span dir="ltr"><<a href="mailto:maurice@bcs.org.uk">maurice@bcs.org.uk</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;"> +<div class="im">On Fri, 01 Oct 2010 09:51:34 +0300, atilla ontas wrote:<br> +<br> +> I'm just wondering if we follow Mandriva's release cycle model. Every<br> +> 6th months a release or one year and one release. I think we should<br> +> make one release in one year.<br> +<br> +</div> I feel the same way, but from an income point of view Mageia would<br> +probably be better off with 2 per year.<br> +<div class="im"><br> +> Do we follow Mandriva's release naming scheme? I.e.<br> +> do we call our first release 2011.x ?<br> +<br> +</div> Incorporating the year number is a big help.<br> +<font color="#888888"><br> +--<br> +/\/\aurice<br> +<br> +<br> +</font></blockquote></div><br><div style="visibility: hidden; display: inline;" id="avg_ls_inline_popup"></div><style type="text/css">#avg_ls_inline_popup { position:absolute; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; width: 240px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 13px;}</style> diff --git a/zarb-ml/mageia-dev/attachments/20101001/efccb7f2/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20101001/efccb7f2/attachment-0001.html new file mode 100644 index 000000000..ff64fc361 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101001/efccb7f2/attachment-0001.html @@ -0,0 +1,48 @@ +<br><br><div class="gmail_quote">On Fri, Oct 1, 2010 at 00:43, Michael Scherer <span dir="ltr"><<a href="mailto:misc@zarb.org">misc@zarb.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<br> +Yup, the distro that make you become expert, something like that.<br> +<br> +One thing we must not forget is that we need people that contribute if<br> +we want to survive. A commercial distribution requires money ( and<br> +therefore users that can bring money , either directly, or either<br> +indirectly ( service, ads, etc )) to survive. We are not a commercial<br> +distribution, so the pressure is lower with regard to money. But we<br> +still to have people that develop it, and if we cannot pay people for<br> +that directly ( since we are not a company, even if maybe some companies<br> +will help us later ), we need to directly use contributions as a way to<br> +ensure our own sustainability.<br> +<br> +SO IMHO, this is what we should seek if we want to survive. Gathering<br> +contributions should be one of our goals.<br> +<br> +The second point is that we are here because we want community<br> +empowerment. So community also must be a strong point, especially since<br> +it will appeal to people that would allow the community to survive.<br> +<br> +So again, I think that empowerment should be another one of the goals.<br> +<br> +Now, we must ask ourself "what is pushing people to contribute".<br> +There is various papers, like this one<br> +<a href="http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/1113/1033" target="_blank">http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/1113/1033</a><br> +<br> +( I let the analysis as a exercise for the moment ).<br> +<br> +And we need to find a way to combine this with others goals.<br> +<br> +While a traditional motivation in free software is to solve our own<br> +problem ( and that's also part of community empowerment ), this is not<br> +enough. We also need to think to more than us. And I think that's the<br> +complex part.<br> +<br> +We have 2 choices. Either we try to find a market where no one went, or<br> +a market where someone went, and try to be better. Or maybe both.<br> +<br> +--<br> +<font color="#888888">Michael Scherer<br> +</font><div><div></div><br></div></blockquote></div>I agree.<br><br>One way towards that goal is something I thought about since some years :<br>lessen the divide between the GUI and CLI approach to computers, and OS's in particular. And thus between the 'user' and the 'geek' cultures (even if geeks are users too).<br> +<br>In particular : that the GUI tools, for example the GUI draktools, provide a link (button) to a short explanation of how they do what they do. For example : what are the configuration files that are changed, and how.<br> +<br>It could be seen as an extension of what is possible with an icon of the Panel : a right-click gets you to see what it does : the command is visible.<br><br clear="all">When I was teaching an introduction to OS's, I used Mandr/ake/iva this way for<br> +people mainly familiar with Windows : the GUI functions are similar, even if different, but you can have a 'readable text' access to what really happens.<br><br>At first I just told them which configuration files where concerned. Later I wrote some simple perl scripts using fileschanged (<a href="http://fileschanged.sourceforge.net/">http://fileschanged.sourceforge.net/</a>)<br> +to let them find it themselves. But there were many limitations : for instance KDE configurations are not writen to file directly.<br><br>Anyway it would be much more helpful if it is incorporated in the GUI tool itself (eventually as an option).<br> +It would encourage progressive exploration of the underlying workings.<br>For anybody, but evidently exploratory behavior is more prevalent in younger people.<br><br>Viewed with some optimism, if this approach is extended, it could lead to an experience similar to that of people who came to programming through contact with the early 8 bit microcomputers. (Many people lament the disapearence of that path of access).<br> +<br>From the 'magic' point of view it would point to : Magea : the School of Magic<br><br>-- <br><br>Frederic<br> diff --git a/zarb-ml/mageia-dev/attachments/20101001/efccb7f2/attachment.html b/zarb-ml/mageia-dev/attachments/20101001/efccb7f2/attachment.html new file mode 100644 index 000000000..ff64fc361 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20101001/efccb7f2/attachment.html @@ -0,0 +1,48 @@ +<br><br><div class="gmail_quote">On Fri, Oct 1, 2010 at 00:43, Michael Scherer <span dir="ltr"><<a href="mailto:misc@zarb.org">misc@zarb.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> +<br> +Yup, the distro that make you become expert, something like that.<br> +<br> +One thing we must not forget is that we need people that contribute if<br> +we want to survive. A commercial distribution requires money ( and<br> +therefore users that can bring money , either directly, or either<br> +indirectly ( service, ads, etc )) to survive. We are not a commercial<br> +distribution, so the pressure is lower with regard to money. But we<br> +still to have people that develop it, and if we cannot pay people for<br> +that directly ( since we are not a company, even if maybe some companies<br> +will help us later ), we need to directly use contributions as a way to<br> +ensure our own sustainability.<br> +<br> +SO IMHO, this is what we should seek if we want to survive. Gathering<br> +contributions should be one of our goals.<br> +<br> +The second point is that we are here because we want community<br> +empowerment. So community also must be a strong point, especially since<br> +it will appeal to people that would allow the community to survive.<br> +<br> +So again, I think that empowerment should be another one of the goals.<br> +<br> +Now, we must ask ourself "what is pushing people to contribute".<br> +There is various papers, like this one<br> +<a href="http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/1113/1033" target="_blank">http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/1113/1033</a><br> +<br> +( I let the analysis as a exercise for the moment ).<br> +<br> +And we need to find a way to combine this with others goals.<br> +<br> +While a traditional motivation in free software is to solve our own<br> +problem ( and that's also part of community empowerment ), this is not<br> +enough. We also need to think to more than us. And I think that's the<br> +complex part.<br> +<br> +We have 2 choices. Either we try to find a market where no one went, or<br> +a market where someone went, and try to be better. Or maybe both.<br> +<br> +--<br> +<font color="#888888">Michael Scherer<br> +</font><div><div></div><br></div></blockquote></div>I agree.<br><br>One way towards that goal is something I thought about since some years :<br>lessen the divide between the GUI and CLI approach to computers, and OS's in particular. And thus between the 'user' and the 'geek' cultures (even if geeks are users too).<br> +<br>In particular : that the GUI tools, for example the GUI draktools, provide a link (button) to a short explanation of how they do what they do. For example : what are the configuration files that are changed, and how.<br> +<br>It could be seen as an extension of what is possible with an icon of the Panel : a right-click gets you to see what it does : the command is visible.<br><br clear="all">When I was teaching an introduction to OS's, I used Mandr/ake/iva this way for<br> +people mainly familiar with Windows : the GUI functions are similar, even if different, but you can have a 'readable text' access to what really happens.<br><br>At first I just told them which configuration files where concerned. Later I wrote some simple perl scripts using fileschanged (<a href="http://fileschanged.sourceforge.net/">http://fileschanged.sourceforge.net/</a>)<br> +to let them find it themselves. But there were many limitations : for instance KDE configurations are not writen to file directly.<br><br>Anyway it would be much more helpful if it is incorporated in the GUI tool itself (eventually as an option).<br> +It would encourage progressive exploration of the underlying workings.<br>For anybody, but evidently exploratory behavior is more prevalent in younger people.<br><br>Viewed with some optimism, if this approach is extended, it could lead to an experience similar to that of people who came to programming through contact with the early 8 bit microcomputers. (Many people lament the disapearence of that path of access).<br> +<br>From the 'magic' point of view it would point to : Magea : the School of Magic<br><br>-- <br><br>Frederic<br> |