зеркало из https://github.com/mozilla/gecko-dev.git
96 строки
4.9 KiB
Plaintext
96 строки
4.9 KiB
Plaintext
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
|