I quit the ML because I was not doing it right + (never used a list like that before).
+
+ So if I may, I will post here what somebody responded to me and + write my response here.
+
+

+
complete rolling release would put a QA strain on each of + the levels. think
+ about it, it's not only the current package being updated, but + also the
+ combinations with other packages. (AND also all the long time + supported
+ versions)
+
+ This would mean that for each package being release, it'll + have to work with
+ the current set of other packages, but also with the packages + you'll be doing
+ next.
+
+ if you have this constant level of QA, you need alot of + resources (which we
+ don't have in QA), and as an extra result, you'll not have the + same level of
+ QA you could have, when you're doing a release.
+
+ it's much easier (as devs) to just choose a subset of + packages, and test those
+ out.
+
+ if you have X QA-devs, and you have 1 subset of versions of + packages, you can
+ test alot more than if you have several versions of several + packages that need
+ to work all with each other in almost any combinations...
+
+ not to mention that you need an extra step with QA to put a + "group" of
+ packages from one level to the next...
+
+ sorry, but with our current resources, i vote no. i want + current resources to
+ be used much more efficiently than with a rolling release.
+

+
+
+ 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!
+
+ 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...
+
+ 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.
+
+ 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!
+
+ What about this? Get the community involved!

I quit the ML because I was not doing it right + (never used a list like that before).
+
+ So if I may, I will post here what somebody responded to me and + write my response here.
+
+

+
complete rolling release would put a QA strain on each of + the levels. think
+ about it, it's not only the current package being updated, but + also the
+ combinations with other packages. (AND also all the long time + supported
+ versions)
+
+ This would mean that for each package being release, it'll + have to work with
+ the current set of other packages, but also with the packages + you'll be doing
+ next.
+
+ if you have this constant level of QA, you need alot of + resources (which we
+ don't have in QA), and as an extra result, you'll not have the + same level of
+ QA you could have, when you're doing a release.
+
+ it's much easier (as devs) to just choose a subset of + packages, and test those
+ out.
+
+ if you have X QA-devs, and you have 1 subset of versions of + packages, you can
+ test alot more than if you have several versions of several + packages that need
+ to work all with each other in almost any combinations...
+
+ not to mention that you need an extra step with QA to put a + "group" of
+ packages from one level to the next...
+
+ sorry, but with our current resources, i vote no. i want + current resources to
+ be used much more efficiently than with a rolling release.
+