[ardour-dev] the development process

[Paul Davis]

there has been some concern raised about my comments on the status of
bug fixing in ardour, and i think i need to clarify the issue a little
more. 

in general, i would rather see the development of ardour as a
continual, ongoing process that makes the current of things available
on a periodic basis (as a "release"). rather than there being a
definitive "this is it", there needs to be more of a "this is where it
is now". 

however, every so often, it is necessary to do something that doesn't
fit into this scheme, and we are about to hit just such an effort.

porting ardour to GTK2 is more or less completely orthogonal to all
the bug fixing that has been going on recently. we have to do this
port because the visual appearance of ardour is important, and because
GTK2 has important improvements in both visual appearance and
usability (both for the programmer and user). there are things we want
to provide for the user that are either impossible or way to hard to
do with GTK1.

it would be really be stretching the resources of the absurdly small
development group here way to far to attempt to do try to continue
with regular bug fixing at the same time as this port.

so, it becomes necessary to declare a milestone. a milestone is an
artificial marker along the way. its meaningless in most senses, but
not all. the milestone is "1.0". "1.0" doesn't mean "we have fixed all
the bugs in ardour, go use it". it means "this is now a very useful
program, that like almost all programs continues to have but
nevertheless can be a very useful tool for many people who have some
interest in audio work".

Is 1.0 a "stable and reliable" release? From the reports I get via
email and on IRC right now, my impression is that its a very very
usable program with some rough edges for the common case, and some
serious issues remaining for some of the more intense/serious uses it
will hopefully see. 

Are there still serious bugs? You bet. Are there still dozens of less
serious bugs? Of course. Can we port to GTK2 if we continue to remain
focused on these items? Definitely not.

The port to GTK2 is something that is hard to predict the duration
of. In theory, it shouldn't take very long - a moderately sized GTK1
project free of new C-level widgets can probably be ported in a
day. But we have a relatively large project here (in terms of lines of
GUI code), and we have several custom C-level widgets. We also have
the canvas, which we'd like to use a newer version of along with a C++
wrapper. I am optimistic that it can done in a month, less if more
people help out. This is a totally divide-and-conquer task. People can
volunteer to get a single source file working (as in "compiles"). The
only really hard parts are getting our custom C-level widgets to work,
and using C++ for the canvas, and i will be starting with those
myself. If we had 10 extra code-monkey volunteers, I imagine we could
get this done 3-5 times faster. Hint.

It will be done in a way that will allow us, theoretically, to
continue to fix issues with the GTK1 version, because we will fork the
gtk_ardour and gtkmmext directories to new versions. Stuff can still
be corrected in the GTK1 directories without affecting the port
directly. But we don't really want to do this too much, because it
will dramatically slow the port down - every time we fix something in
the gtk_ardour directory, we have to resync with it in the gtk2_ardour
branch. 

So what does this mean in practical terms? If there are still serious
issues outstanding that can be fixed by a relatively quick inspection
of the source code, a rapid determination of the problem and a fix
completed in a few hours or less, these things *will* get fixed before
1.0 is released. The only real absolute bar on such things will be in
the interval between 1.0rcN and 1.0, when the source code should not
change at all. If such things show up in Mantis after the 1.0 release,
we will have to balance their seriousness with the cost of slowing
down the port. If an obviously desirable task, for example using MMC
ffwd and rev buttons, causes crashes and we know how to fix it, it
will get fixed. If its something that I/we don't understand, and/or
cannot replicate, then it will sit in the queue in Mantis and wait
till after 2.0 is released.

But if anybody wants to see the port go smoothly and rapidly, they
should understand that fixing bugs during this time will only slow it
down, possibly dramatically.

I need to remind everyone that at this point in time, Ardour continues
to a volunteer, unpaid project to implement the functionality of some
of the most complex software ever written. The donations are wonderful
and highly appreciated, but this is a project that exists only because
the developers and contributors to it design want to work on it to
whatever extent they can. I'd love to know that Ardour was ready to
stand in for any commercial DAW, and I believe that one day it will
be. The fact that serious issues remain should not act as an obstacle
to us getting on with one of the most important tasks related to
getting it closer to that goal.

--p