Skip to main content

Where are the flying cars?

Posted by peterkessler on December 17, 2004 at 4:32 PM PST

We've published 5

Mustang builds
so far. But there hasn't
been much to write home about. We've made some

steady progress
, but no sweeping language changes, no
major new library packages, no ports of the virtual machine
to new platforms. We haven't even implemented all of the href="">
suggestions from this forum. What's taking us so long?

It's probably worth giving people a heads up on how the
Mustang release is going to progress between now and when we
declare it done.

Right now we are mostly fixing bugs we didn't get into
Tiger. (You'll see, this will happen again at the end of
Mustang, with fixes we'll push off to

.) We're also cleaning up code and other small
chores while we work out what new things to get into
Mustang. There are lots of sources of good new ideas: while
we were working on Tiger we talked to a lot of people about
what we should do next, the Java community process has some
big ticket items, our licensee partners have porting and
tuning concerns, this forum is full of smart people, etc.
We are also starting to field feedback from people who are
using the new features we put into Tiger. All that goes
into planning for Mustang. There's no shortage of bug
reports, RFE's, suggestions for tuning, good ideas (and some
not so good ones). We have a long list of things we want to
do; the trick is figuring out what we can get done well in
Mustang. Soon the planning will die down and we engineers
will be heads down writing code.

But for you watching the snapshot builds come out: a note of
caution. Things will probably get rough before they get
better. All that new code will come with unit tests, but
those don't catch all the bugs. We have a whole quality
engineering team to write additional tests, but they are
coming up to speed on the new features too, and sometimes
they read the specs more carefully than the developers do.
There are the JCK tests to write, too. QE is always behind
when whole new API's are in flux. We have a quality
assurance team to run all the tests on all the instruction
sets and operating systems we support, in various locales,
on all sorts of weird graphics cards, etc., but it takes QA
a while (weeks, months) to cover the more obscure

Different groups have different strategies to balance working
on new features and fixing bugs. Some teams have some
designated bug fixers for a release, to leave other people
free to focus on new features. Some groups have everyone
fix bugs in and around working on new things. Some groups
have people now working on features that we know won't be
ready until Dolphin. And it's not like we have a set list
of bugs to be fixed that we just work our way
through. Sometimes we introduce new bugs in spite of our
code reviews and unit testing, and you might trip across
bugs those in the snapshot releases. (And you'll
report them,
I hope, so that we can get them fixed.)

Probably what you'll see in the snapshots -- unfortunately --
is a temporary decrease in quality. And steps backwards in
overall performance, footprint, startup time, etc. Oh, the
snapshots are not as bad as all that. Those builds have been
through individual engineer and group testing, integration
testing with other groups, and as much testing as we can get
in while still getting the snapshots out to you in less than
a week. Mustang might be different because we are trying
some new ways of managing things: e.g., putting the
snapshots out so people can try them earlier and
file reports
on bugs they find. And, we'll be accepting -- real soon now
-- bug fixes and features from you folks. But I
thought I should warn you that you might not see continuous
improvement. The advantage of the snapshots is that you get
to see the new features first, try them out, exploit them in
your code, and give us feedback and suggestions for
improvement. Things will get better.

At some point the axe will fall, and new features won't be
allowed into Mustang. (Well, it's not as sharp a line as
that. There are business reasons, and late JSR's, and
pressure from one or another of our valued licensees, etc.,
that make this process a "slush" rather than a "freeze".)
The idea of drawing a line is to give the QE folks time to
finish writing tests for the features, and to give the QA
folks time to run all their combinations. The documentation
folks come around and figure out what's new and how to
explain it in the release notes and web pages. New
development doesn't stop, but it does slow down. People who
didn't get their features into Mustang switch to getting
those features into Dolphin. But finding and fixing bugs
becomes a higher priority. And the review and testing bar
gets higher for any changes. Also, once the release settles
down we can do integrated performance analysis and work on
other aspects of quality we can't do until we know what we
are working with. So later in the release cycle you'll see
a marked improvement in quality.

At some point, the bar for putting back changes gets so high
that we'll turn down even obvious bug fixes that wouldn't
have been given a second thought early in the release.
Those will go into Dolphin, and then get back-ported to the
updates to Mustang. (How can I be thinking, now, about
updates to Mustang? Because the big wheel goes around, with
the little wheel inside it.) And we'll be asking around
again about priorities and features and what we should do next.

I hope that gives you a sense of what to expect in the snapshot
releases and how we might deal with suggestions -- or code
-- you might contribute.

Don't look for flying cars in the first few snapshot
releases. They'll be along later.

Related Topics >>