[dev] RE: [imp] Help with attachments

[Eric Rostetter]

Quoting "Roger B.A. Klorese" <rogerk at queernet.org>:

> > I hate that kind of schedule.  Basically "We'll release a
> > version every <X time units> whether it is ready or not!"
[...]
> It has some benefits, though, combined with a feature list: it allows IT
> organizations to plan their upgrades and staffing.

Not as useful as you'd think, since I need to wait and see if the new
release is stable or not.  I'd rather they wait for a stable release than
make a scheduled release.  So now with RedHat I have to either:

* Install and test it before I deploy it (meaning I need more hardware for
the testing) and hope I catch all the problems before I deploy.

* Wait for the vendor (e.g. Dell) to certify it for their machines, which has
no fixed timeframe and may take most, all, or even more than all of the release
cycle (the vendor may not certify version X until after the following version
Y is already out).

I don't see any advantage to this kind of release scheme.  I've lived my
entire life without it until recently when RedHat went to it, and I'd rather
continue to live without it.

> The question, though, is: what even remotely objective process determines
> what changes (other than security) justify a release?

Who said it had to be objective?  Or that it even should be objective?

--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!