[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Faster Release Cycle = More Up to date Packages...

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

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

Reply to: