Posted by: Administrator
on March 28, 2007 08:52 AM
I am concerned time based releases, not because of style, but because of too short a time between releases, with too many changes occurring per release.
Here is my argument as to why we should slow down.
Two years ago there were about 6000 modules in linux, with around 4000 being critical. The cartesian product of 4k by 4k is what we should have as critical tests to confirm correctness of execution. In these tests, when a bug is found, partial retesting is required. Suppose there were really 4k*4k or 16k tests to assure that release.
Today (two years later), with enhancments to X, to the kernel, virtual operating system execution, to the applications, and growth in number of new applications (modules), we have over 8,0000 modules of which 6000 are easily installed (a count I derived from my own linux desktop system).
Drawing on the same logic, we should have 6k*6k or 36k tests to perform to assure a clean distribution.
The qualitive ratio of module counts from two years ago to today is 36/16, or more than double the number or required tests to maintain the same quality.
But we do not have double the number of test people, and we have not increased the time between releases. Nor have we automated the testing procedures.
My take on this is that I have definitely experienced a very much larger number of bugs in the maintenance updates now,from what I experienced two years ago. In fact, I would say that the number of bugs has gone up by the square of the number of bugs reported two years ago, or more than the ratio of 36/16.
My conclusion is that we require a kind of Moores law for deciding when to schedule/time a new release.
As the number of modules increases, so must the testing times increase exponentially.
My experience over 40 years in IT/development leads me to recommend fixed releases, but not necessarily on a periodic (example 6 monthly) schedule, but rather that they be based on the number of program changes that occur in a 3 month period following the previous release.
Leslie Satenstein
From October to today, my favourite linux distribution has listed over 325 bug fix patches. There should only be not more than 2 per week or 20.
Learn about Linux
Download Linux
Get Linux help
time based releases
Posted by: Administrator on March 28, 2007 08:52 AMHere is my argument as to why we should slow down.
Two years ago there were about 6000 modules in linux, with around 4000 being critical. The cartesian product of 4k by 4k is what we should have as critical tests to confirm correctness of execution. In these tests, when a bug is found, partial retesting is required. Suppose there were really 4k*4k or 16k tests to assure that release.
Today (two years later), with enhancments to X, to the kernel, virtual operating system execution, to the applications, and growth in number of new applications (modules), we have over 8,0000 modules of which 6000 are easily installed (a count I derived from my own linux desktop system).
Drawing on the same logic, we should have 6k*6k or 36k tests to perform to assure a clean distribution.
The qualitive ratio of module counts from two years ago to today is 36/16, or more than double the number or required tests to maintain the same quality.
But we do not have double the number of test people, and we have not increased the time between releases. Nor have we automated the testing procedures.
My take on this is that I have definitely experienced a very much larger number of bugs in the maintenance updates now,from what I experienced two years ago. In fact, I would say that the number of bugs has gone up by the square of the number of bugs reported two years ago, or more than the ratio of 36/16.
My conclusion is that we require a kind of Moores law for deciding when to schedule/time a new release.
As the number of modules increases, so must the testing times increase exponentially.
My experience over 40 years in IT/development leads me to recommend fixed releases, but not necessarily on a periodic (example 6 monthly) schedule, but rather that they be based on the number of program changes that occur in a 3 month period following the previous release.
Leslie Satenstein
From October to today, my favourite linux distribution has listed over 325 bug fix patches. There should only be not more than 2 per week or 20.
#