From: "Mike A. Harris" <mharris@meteng.on.ca>
Subject: Linux 2.4 before 2001?
Date: Wed, 5 Jan 2000 03:53:26 -0500 (EST)
> This brings up a point: Why do developers of the kernel, or any
> other software project for that matter - give bunk projected
> release dates at all? It introduces the "vaporware" concept, and
> makes things look bad. In reality, there are so many people
> working on the kernel, that at any point, some major cool new
> feature, patch, speedup, or whatnot can happen, and often does,
> and this often pushes the stabilization and release back a month
> or more.
There are some refreshing comments in "The Mythical Man Month" by Brooks.
While not all the truth is found there, it shows some issues and at least shows
that it is a complex issue and not all the issues are instantaniously obvious.
Maybe we are just trying to get a too large bite of features done at the same
time.
> Since this is unlikely to change, why not just stop projecting
> the release dates entirely? It is something unpredictable.
> A lot of major companies flat out refuse to give dates on things
> because they don't want dissappointed customers when the date
> can't be met. Why don't we all take the same approach too?
> After all, the date of release is not going to be forced due to
> bad projections giving expectations right?
Ah, like Debian for instance... if you drift for too long you get the bad
press for NOT saying anything.
> So, my whole point here is: Do not project the major kernel
> release dates as it is bad press. It gets expectations up, and
> lets some people down. Even far speculation is bad because
> people will turn it into a serious release date. So saying
> "maybe by the end of the year" will be turned into "oh it is
> definitely coming out by the end of the year" by someone else".
>
> All in all, linux will be released "when it is done" which is
> more or less id software's release policy. Why don't we adopt
> the same policy?
In principle yes, but I think that there should be some mechanism along with
that which forces releases somewhat more frequent. If we say a date we can
feel guilty for not deliver on time and use that to bang people in the head
and say "No, not in this release" where as we would loos that and be able to
put up some other way of forcing a release even if the hacker in us wants more
into it. Smaller steps. Maybe one should open up a new development path as one
say "freeze" on the current so that one can redirect requests for the next
development tree and have those efforts start early in the branch.
Regardless of what we say, I think we must figure out how to increase release
frequency while maintaining the quality level. I'd say go for smaller steps
in additional features and get those in early so that stabilization may occur.
It's a balance and there will allways be opinions on the release times.
Cheers,
Magnus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:04 EST