Monty on MySQL 5.1 [LWN.net]

Monty on MySQL 5.1

Posted Dec 1, 2008 22:47 UTC (Mon) by nix (subscriber, #2304)
In reply to: Monty on MySQL 5.1 by sbergman27
Parent article: Monty on MySQL 5.1

This isn't desktop software, though. Databases are kind of special, like
filesystems: a huge variety of bugs in them can be data-loss bugs, and
when you lose data you can lose a *lot* at once.

As such, the priority must *always* be quality, specifically
lack-of-data-loss quality. It's no good if a DB is released sooner if it
eats your data once you install it. Prioritizing time-based schedules over
quality helps only the vendor, not the users.

(PostgreSQL gets this right: note their massive backports of any data loss
bug, often to five-year-obsolete releases, simply because users upgrade to
new major versions of databases extremely rarely, but still consider data
loss bugs crucial to fix.)

(Log in to post comments)

Monty on MySQL 5.1

Posted Dec 1, 2008 23:10 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

quality and time-based releases do not need to be exclusive.

using your example, Postgres does time-based releases, but they also do a very good job of policing what features go into each release.

time based releases are a problem when the emphisis is on the release schedule and the feature checklist (with quality dropping off if nessasary). if the emphisis is on the release schedule and quality (with features being allowed to drop off if they aren't ready) it's not a problem.

Monty on MySQL 5.1

Posted Dec 1, 2008 23:48 UTC (Mon) by pboddie (subscriber, #50784) [Link]

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".

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.