David Jardine wrote: > On Tue, Jan 06, 2009 at 12:28:44PM -0800, Ken Teague wrote: >> Barclay, Daniel wrote: ... > > Well, maybe I'll prove to be understanding neither of you, but the > point seems to be that you can't 'force' the maturity of a package.
I wasn't talking about trying to force the maturation of any changes to go faster; I just meant dividing the changes into two (or however many) groups so the first group could be implemented, "matured" and released before the second group got started. That shouldn't increase the _explicit_ development, testing, and fixing effort required. (Of course, as I said, there is also the additional (presumably significant) overhead of making and tracking an additional release in the middle.) On the other hand, that division admittedly does reduce the _time_ during which a change group is implicitly tested by being used. (Instead of having both sets of changes being tested for duration D, each gets tested for only duration D/2). So I guess that question is how significant that testing duration is (compared to the number of people implicitly testing, etc.). > Halving the seed rate in a field of wheat won't make the wheat ripen > twice as fast. But breaking an ice cube in half does help it melt faster. The question is which analogy is actually ... um ... analogous (or, probably more accurately, how much each applies to this case). Daniel -- (Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]
