Johnny Ernst Nielsen: Don't worry about flames launched by cranky developers who didn't get what they wanted for their birthdays. Many of us haven't read _every_ posting on _every_ debian list for the past six years and may therefore once in a while bring up some issue that has been discussed previously. The appropriate way to deal with poor people like ourselves it to post URLs for relevant threads we should read. I think your suggestion has some merit. Torsten Landschoff replied that "This was the whole idea of testing. Experience shows it does not work." I think testing is an excellent thing to have, since it provides a semi-stable proto-release. Unfortunately it is true that the existence of testing hasn't shortened the release cycle. Ben Collins offered what amounts to a possible explanation for this. He says that it is the rate of bug fixing that determines how fast the next release gets out. Since the rate of bug fixing is fixed, therefore the release cycle cannot be speeded up. (I hope that is a faithful summary.) But this argument fails for two reasons. Mr. Nielsen's proposal is designed to speed up the release schedule, not to increase the bug-fixing throughput. Instead of doing 100 units of bug-breeding development followed by 100 units of RC debugging, he suggests doing 50 units of development, 50 units of RC debugging, 50 units of development, 50 units of RC debugging. Of course it's far from being so simple as that, but the overall idea seems sound. If we take smaller bites, we will have less to chew and less to swallow. Our throughput might even increase (no gagging ... fewer Heimlich maneuvers required). The second reason that B.C.'s argument fails is that a shorter cycle might encourage greater effort on the part of the volunteers. Under the current system, the periods during which maintainers concentrate their efforts so that they can get their packages "ready for release" are fewer and farther between than they might be. Under the current process there are long periods when bugs can be ignored because the release is years away. We have seen members resign in frustration with the sluggishness of the whole process. More frequent releases, brought about by means of Mr. Nielsen's suggestion, might evoke greater total effort. We don't want releases so frequent that they cease to be important events, but the current release schedule is, I would guess, not optimally harnessing the resources that we have.
Attachment:
signature.asc
Description: This is a digitally signed message part