Recent Features
| |||||||||||||
Monty on MySQL 5.1Monty on MySQL 5.1Posted Dec 1, 2008 21:45 UTC (Mon) by sbergman27 (subscriber, #10767)In reply to: Monty on MySQL 5.1 by pboddie Parent article: Monty on MySQL 5.1
I disagree that time-based releases are bad. With good project planning and management, it can work quite well. That means keeping the new feature list reasonable, being able to say "No" when required, a willingness to drop features that just aren't really ready in time, and reasonable flexibility in delaying the release some *if* that becomes necessary due to some unforseen, last minute problem. Time-based releases actually encourage good, agile development practices. Obviously, they can also be a disaster if the project leader, BDFL, or whomever doesn't handle it right.
I felt like the really disturbing bit from the article was:
"""
You might recognize the old "present it as more stable than it is to trick people into testing for us" technique. Although this is not the worst example. Some well known FOSS projects actually release alpha quality code as GA.
(Log in to post comments)
Monty on MySQL 5.1 Posted Dec 1, 2008 22:47 UTC (Mon) by nix (subscriber, #2304) [Link]
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
(PostgreSQL gets this right: note their massive backports of any data loss
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.
Monty on MySQL 5.1 Posted Dec 2, 2008 7:55 UTC (Tue) by nix (subscriber, #2304) [Link]
That is, note PostgreSQL's massive backports of any data-loss bug *fix*.
Oops.
Nobody is perfect, but... Posted Dec 2, 2008 9:09 UTC (Tue) by khim (subscriber, #9252) [Link] That is, note PostgreSQL's massive backports of any data-loss bug *fix*. It's one thing to port fix for previously unknown data-loss bug, it's totally different thing to declare thing as stable when it contains known data-loss bugs. I like MySQL but this latest trend of adding pile of features without proper testing is quite worrysome.
|
|||||||||||||