| |||||||||||||
Monty on MySQL 5.1Monty on MySQL 5.1Posted Dec 1, 2008 23:48 UTC (Mon) by pboddie (subscriber, #50784)In reply to: Monty on MySQL 5.1 by dlang Parent article: Monty on MySQL 5.1
time based releases are a problem when the emphisis is on the release schedule and the feature checklist (with quality dropping off if nessasary). This can also be phrased as "time-based releases are a problem if there's a product marketing/strategy department in the picture". Mostly because arguments about what goes in and what stays out are much harder to resolve when a bunch of people are whining that "they promised something to [impress] a customer".
(Log in to post comments)
Monty on MySQL 5.1 Posted Dec 2, 2008 0:10 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
yes and no.
it depends on who is in charge.
if it's marketing the feature list and time schedule are paramount, everything else must adapt.
if it's not marketing the business can still make the choice between
1. deploying the feature on time but at poor quality.
2. deploying the feature late, but with good quality
3. deploying on time with good quality, but dropping the feature until next time.
one very good thing about time based releases is that you have a pretty good idea what "next time" is, and if it's a relativly short cycle it's not that big a deal to drop the feature for one cycle. If your cycles are unpredictable, it becomes a very big deal to drop a feature (because you don't know how many years it may be before that feature becomes available)
In general I'm a big fan of having fairly frequent time-based releases, but you do need to be aware of the trap that marketing people will try to push you into and avoid it.
Monty on MySQL 5.1 Posted Dec 2, 2008 8:29 UTC (Tue) by drag (subscriber, #31333) [Link]
The reality of the situation is that a buggy time-based release is much more valuable to end users then a stable release that doesn't exist. Software that doesn't exist isn't going to help anybody else.
see also: Debian
The correct approach is to get a stable release on a timely basis. Features be damned. As long as you meet the minimal requirements to get the job done then that's what is most important.. anything else your able to accomplish is gravy.
One of the things that free software folks suffer from is the inability to get their egos out of the way and concentrate on getting minimal functionality _correct_ first, then move onto fancy features next. Instead the tendency is to get basic functionality down first then move onto fancy features while hopping the broken-in-small-ways basic functionality stuff solves itself as time goes by.
Of course, like you guys alluded to the marketing folks push on features first on a time-based basis. Which is a trap of a different, but equally destructive, nature.
|
|||||||||||||