2 files changed, 162 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/attachments/20110614/74831276/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20110614/74831276/attachment-0001.html
new file mode 100644
index 000000000..643ec903b
--- /dev/null
+++ b/zarb-ml/mageia-dev/attachments/20110614/74831276/attachment-0001.html
@@ -0,0 +1,81 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+  <head>
+    <meta content="text/html; charset=ISO-8859-1"
+      http-equiv="Content-Type">
+  </head>
+  <body text="#000000" bgcolor="#ffffff">
+    <br>
+    by <strong><a
+href="https://forums.mageia.org/en/memberlist.php?mode=viewprofile&amp;u=646">corbintech</a></strong>
+    &raquo; Jun 13th, '11, 22:12
+    <div class="content">I quit the ML because I was not doing it right
+      (never used a list like that before).<br>
+      <br>
+      So if I may, I will post here what somebody responded to me and
+      write my response here.<br>
+      <br>
+      <blockquote class="uncited">
+        <div>complete rolling release would put a QA strain on each of
+          the levels. think <br>
+          about it, it's not only the current package being updated, but
+          also the <br>
+          combinations with other packages. (AND also all the long time
+          supported <br>
+          versions)<br>
+          <br>
+          This would mean that for each package being release, it'll
+          have to work with <br>
+          the current set of other packages, but also with the packages
+          you'll be doing <br>
+          next.<br>
+          <br>
+          if you have this constant level of QA, you need alot of
+          resources (which we <br>
+          don't have in QA), and as an extra result, you'll not have the
+          same level of <br>
+          QA you could have, when you're doing a release.<br>
+          <br>
+          it's much easier (as devs) to just choose a subset of
+          packages, and test those <br>
+          out.<br>
+          <br>
+          if you have X QA-devs, and you have 1 subset of versions of
+          packages, you can <br>
+          test alot more than if you have several versions of several
+          packages that need <br>
+          to work all with each other in almost any combinations...<br>
+          <br>
+          not to mention that you need an extra step with QA to put a
+          "group" of <br>
+          packages from one level to the next...<br>
+          <br>
+          sorry, but with our current resources, i vote no. i want
+          current resources to <br>
+          be used much more efficiently than with a rolling release.</div>
+      </blockquote>
+      <br>
+      <br>
+      Why do we keep acting like there is no other way to pool
+      resources? I have never helped develop in any way, teach me
+      something and I'll lend a hand... Others may do the same.. ASK!<br>
+      <br>
+      QA comes from testing... Test... Test... And test more... To make
+      sure what you have works and works well. Let's change up my idea a
+      bit and satisfy everyone... Let's compromise... <br>
+      <br>
+      How about Cooker (or whatever you call) rolls to rolling (can be
+      very stable???!!!) with release cycle releases based on a snapshot
+      of either of the rolling models and supported for X amount of
+      time? This could make those whom want a rolling release model
+      happy and those whom want a release cycle.<br>
+      <br>
+      Would this be hard? I don't really think so as development is
+      already based on a rolling model (cooker or whatever), all that
+      will have to be done is packages roll down the line. I seen in the
+      start of all these talks you wanted to support 3 structures of
+      systems... Here they are!<br>
+      <br>
+      What about this? Get the community involved!</div>
+  </body>
+</html>
diff --git a/zarb-ml/mageia-dev/attachments/20110614/74831276/attachment.html b/zarb-ml/mageia-dev/attachments/20110614/74831276/attachment.html
new file mode 100644
index 000000000..643ec903b
--- /dev/null
+++ b/zarb-ml/mageia-dev/attachments/20110614/74831276/attachment.html
@@ -0,0 +1,81 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+  <head>
+    <meta content="text/html; charset=ISO-8859-1"
+      http-equiv="Content-Type">
+  </head>
+  <body text="#000000" bgcolor="#ffffff">
+    <br>
+    by <strong><a
+href="https://forums.mageia.org/en/memberlist.php?mode=viewprofile&amp;u=646">corbintech</a></strong>
+    &raquo; Jun 13th, '11, 22:12
+    <div class="content">I quit the ML because I was not doing it right
+      (never used a list like that before).<br>
+      <br>
+      So if I may, I will post here what somebody responded to me and
+      write my response here.<br>
+      <br>
+      <blockquote class="uncited">
+        <div>complete rolling release would put a QA strain on each of
+          the levels. think <br>
+          about it, it's not only the current package being updated, but
+          also the <br>
+          combinations with other packages. (AND also all the long time
+          supported <br>
+          versions)<br>
+          <br>
+          This would mean that for each package being release, it'll
+          have to work with <br>
+          the current set of other packages, but also with the packages
+          you'll be doing <br>
+          next.<br>
+          <br>
+          if you have this constant level of QA, you need alot of
+          resources (which we <br>
+          don't have in QA), and as an extra result, you'll not have the
+          same level of <br>
+          QA you could have, when you're doing a release.<br>
+          <br>
+          it's much easier (as devs) to just choose a subset of
+          packages, and test those <br>
+          out.<br>
+          <br>
+          if you have X QA-devs, and you have 1 subset of versions of
+          packages, you can <br>
+          test alot more than if you have several versions of several
+          packages that need <br>
+          to work all with each other in almost any combinations...<br>
+          <br>
+          not to mention that you need an extra step with QA to put a
+          "group" of <br>
+          packages from one level to the next...<br>
+          <br>
+          sorry, but with our current resources, i vote no. i want
+          current resources to <br>
+          be used much more efficiently than with a rolling release.</div>
+      </blockquote>
+      <br>
+      <br>
+      Why do we keep acting like there is no other way to pool
+      resources? I have never helped develop in any way, teach me
+      something and I'll lend a hand... Others may do the same.. ASK!<br>
+      <br>
+      QA comes from testing... Test... Test... And test more... To make
+      sure what you have works and works well. Let's change up my idea a
+      bit and satisfy everyone... Let's compromise... <br>
+      <br>
+      How about Cooker (or whatever you call) rolls to rolling (can be
+      very stable???!!!) with release cycle releases based on a snapshot
+      of either of the rolling models and supported for X amount of
+      time? This could make those whom want a rolling release model
+      happy and those whom want a release cycle.<br>
+      <br>
+      Would this be hard? I don't really think so as development is
+      already based on a rolling model (cooker or whatever), all that
+      will have to be done is packages roll down the line. I seen in the
+      start of all these talks you wanted to support 3 structures of
+      systems... Here they are!<br>
+      <br>
+      What about this? Get the community involved!</div>
+  </body>
+</html>