Design and Architecture 

Bugzilla 3 is being designed from the ground up using a Perl based
technology that has been developed explicitly for the purpose of
developing UI agnostic applications. This technology is called PLIF
and is available as an open source resource from mozilla.org. PLIF has
been developed over the course of the last couple of months by 1
(talented?) developer. PLIF provides the structure necessary to
facilitate the development of web, IRC, command line and other
applications by combining not only a large collection of useful code,
but a model in which to develop these applications. In addition to
using PLIF, we will also be using COSES as the template language for
providing an environment where the HTML/XUL/text/whatever is
completely abstracted from the business logic of the application. We
are aware that people often claim that their applications provide
this, so we have worked hard to insure that this is a reality.

We choose Perl for a few reasons. The first is that the current
Bugzilla 2.x developers are primarily interested in Perl for
developing web applications. Perl has many advantages over other
technologies.  It's fast, stable, portable and easy to write. There
are other languages such as Python and Java that are also popular and
we hope that people will choose to use Bugzilla-3-compatible ideas as
the basis for developing their own front end applications. Just
because we have chosen Perl does not mean that we are adverse to
seeing Bugzilla 3 implemented in multiple different environments, it
is just we needed to make a decision and our first decision and
priority is Perl. :-)

We are not interested at this point in getting into language wars. We
chose Perl because it is a widely used technology that has been proven
to work in large scale systems. As stated above, we feel that
designing a solid foundation will allow anyone to port the UI front
end of Bugzilla to any other language. In fact, we are encouraging
this.

One goal of Bugzilla 3 is to be able to translate from a Bugzilla 2.x
schema to a Bugzilla 3 schema. Given this requirement, the
functionality within the 2.x schema will remain available in Bugzilla
3's schema. For instance, the Milestone field in Bugzilla will become
a generic field called "Milestone" in Bugzilla 3. The only primary
differences between the two will be additional features that are
required by Bugzilla 3 and a more thought out and normalized database
and code design.


Features 

Bugzilla 3's initial goal is to have equal feature functionality to
Bugzilla 2.x, because Bugzilla 2.x is the most used issue tracking
system for OSS projects. While Bugzilla 2.x is a great step forward
from other systems (like GNATS), it is still missing out on a good UI
design, code design and database schema design. So, what we have done
is start with the concepts in Bugzilla 2.x's database schema and
identified areas where it can be improved through better design and
additional database normalization. Since we are using a web
application framework (PLIF) and back end technology (Perl), we will
also kill the code and design problems inherent in Bugzilla with one
stone.

A major problem with Bugzilla 2.x is that it is implemented in such a
fashion that security is not taken into consideration and this has
resulted in being a catalyst for high profiles sites being hacked into
(including apache.org). The fact of the matter is that Bugzilla was
never meant to be used outside of Netscape and the code shows. When
Mozilla.org was created, there was a great hurry to provide some sort
of issue tracking system for people to use. Bugzilla was available
internally at Netscape and there were people at Netscape that knew how
to install and use it. To Mozilla.org's credit (and the contributors
to the project), Bugzilla has grown quite a bit, the TCL/TK
dependencies were removed, the code has been cleaned up quite a bit,
bugs have been fixed and features added. The problem is that this has
been done on top of a poorly designed base which is not only hard to
setup and configure (the first thing you have to do is change the path
to the Perl executable in each and every file!), but also hard to
customize the look and feel of because much of the look and feel is
hard coded in Perl code. It is time to start over with something new
that is designed from the ground up to scale to other people's needs.


Processes 

There are some well defined process's within Bugzilla 2.x that we do
appreciate. For example, the Anatomy of a Bugs Life is a terrific
example of how the whole process of dealing with an issue should
work. However, some people do not wish to use this model, and so
duplicating these rules within Bugzilla 3 is not a priority. Instead,
we instead to make everything customisable and generic. The point we
are trying to convey is that we are encouraging the idea of taking the
good pieces and dropping the bad.


With apologies to the Scarab people [1].

[1] http://scarab.tigris.org/scarab-design.html